 Coming here to Elm Meetup, I really appreciate the opportunity to learn about Elm. It's just sometimes I could not use Elm, I had to use some other language and having it in mind that there are tricks like strong types that really help you with development of certain systems. As we already hear today, I thought, OK, so if there are tricks, we should keep using them if we can. So whenever I can, whenever the team allows and other constraints allow, I try to use them. And I consider the strongly type languages in general to be one of the top tricks of basically our era in terms of programming. The other tricks that I was mentioning is probably fuzzing here. And these two tricks sometimes really go a long way. I mean, I've written a complete application with futiles and lines of code that mostly were tested only by strong types and one really well-designed fuzzer. And that was enough. That fixed all the other problems I had with this application. Besides minor UI issues, which is really serious. So I would say since I've been basically always in the domain of kind of economizing delivery of software, you don't know what you are doing. You just want to learn what you are doing. And in the process, you want to be on some reasonable schedule. Even if you are not certain the schedule is right, I still was doing it all the time. So then these tricks are invaluable. So in this presentation, I will show pure script, which is another language very similar to Elm and Haskell. It allows you to use JavaScript both on the front end and the back end. And that was actually why I was attracted to it because I wanted to use Node.js for something. And I didn't have even access to Node.js server directly. So basically it was constrained environment. Because you can use Elm test to run the things on the back end. But at the moment it's not apparent for me how to do it in Node.js server hosted somewhere else like Lambda, AWS. Or I will show another example, which is Game of Scripts. I predict that there will be more and more platform like this, where you just put any JavaScript, hopefully soon any WebAssembly. And you can run it because that's a very, very well controlled environment. It's like containers are preferred to giving you a whole virtual machine. So since we are in the cloud development, a lot of us, I think it will be of increasing interest. You send the code that is JavaScripty and you get whatever you want done. And you don't need to worry about management, but on the other hand you have to run it somewhere where you don't really know what it happens. So it's very close to pure JavaScript. Sometimes I tested some things as pure JavaScript first just to make sure that it will work at all on the server. Because it may be kind of weird JavaScript environment. Like WebWorkers, I think, are a bit weird if you look at it. But you would like to write WebWorkers code in Elmwood India. And that's basically what drove me to try PureScript. So I will demonstrate it in a browser for the Node server and as AI for Scripts.com, for which I think I published open source. Basically I took open source library for wrapping JavaScript function into PureScript. It was very easy. I will show how to do it and put a new version with better types. And then we can talk about advantages of Elm and PureScript. Since PureScript and Elm are very close and Elm has very, very many advantages in terms of speed and code size. I would really like to see future inter-twin meaning or somehow shifting of the features between languages because both opinionated Elm, which gives very, very high quality solution and kind of very elastic PureScript have their advantages. And by the way, I already told I'm now a senior developer in dual payment tech and we are hiring. We are hiring front-end programmers, so front-end back-end, so in case you want. And I will basically show the FFI example. I think I mentioned that. So this is the first example. So the first awareness is that your NPM install, Post-PureScript compiler then you use a different package manager, which is Bauer to install every PureScript library. Even if you use it on the back-end, it's usually in Bauer. I understand that authors just converge on Bauer as a better package manager than NPM is in their opinion because Bauer is basically using mostly things hosted on GitHub. So it doesn't require much hosting. Also it directly refers to GitHub commits. So basically when you register package to Bauer, you send information. This is my GitHub repository and this is my commit. And that's what we are seeing more and more often. You see VIM plugin managers that also do that because GitHub nicely provides both hosting service and the repo service. And that's killer application. And that means that so many headaches are gone. Then after you do this and you write your program in SRC repository, you use a PULP build. This is basically a builder that generates JavaScript. So that's kind of similar to Elm, but maybe a little bit different. Then the second wordness here is that instead of having this prescribed model view, it took a different route where you have an EFF monad that can do literally everything and is imperative basically. So in EFF monad, you can have any effect as long as you declare it. And here we see there is console effect, which basically means that I'm writing to console. And there is polymorphism EFF, which means maybe I will do something else, but I don't know, I didn't decide. Maybe other parts of the program would want to do this. So log is basically printing to the console. It's console log in JavaScript. And log show is first applying a show function that is the same in both languages and then logging it. So the starting is very similar. This is the simplest program. And the only reason that I picked PureScript was that I can run it on the server so quickly. I don't need to... Because this is yet functionality that you want to see in EFF. Now PureScript in a browser is not much different. There is a little bit more imports that I skipped here to add usually for things like monads. You sometimes need to import control monad or control monad EFF for everything to work because it's very, very fine in imports. That's in order to reduce code size. I think there is still a little bit room for improvement in this regard because I've seen the code included. It was a bit more, but I usually got my stuff in one or two megs of JavaScript. So even after all includes and I use a lot of libraries usually. Then you see a little bit different way because if you say import jQuery library then you can program in jQuery style. So this ready is basically document ready function. So if when ready you start doing something very similar to this JavaScript. So this is essentially imperative. It's a little bit less safe, but sometimes it allows you to do certain tricks where you want to kind of control your framework or do something in cutting the corners. So here you just... In ready function you pick the body of the document and then you create a diff. These are all imperative actions like appending the new element to the diff or the body. It depends what you want really. So I guess if you are starting the really pure front end application with constraints on basically the big team and you really want maximum safety, you probably still want Elm style because Elm will prescribe this model view system and will prevent this imperative tricks. But if you are on the corner, you want to use a lot of JavaScript libraries as I usually unfortunately do. So I'm really pulling on the existing open source code whenever I can. Then you may use the jQuery directly. You know that the jQuery already has the knowledge there in JavaScript community. Another example is actually the example that I found. I think this is one of the only compilers that work so easily here. It's that you have this node server that is controlled by somebody else somewhere far. So you just give them JavaScript code and you expect this code to be behaving like the JavaScript code that they give you in the example. In this case, this is imperative code that is run every turn of the game and every turn is about three seconds now. Initially it was expected to be one second but number of players increases even with all the parallelization. So it is run every second. It has I think now between 30 or 600 milliseconds to run per player depending on the player's level. And in this time it can query the world and you need to be very careful about this because if you just attempt to do it in a pure functional way and query all the information you can, it will be too slow. You will exceed the time. The time limits are very strict especially if you do a lot of allocational memory. And if you query a lot of objects, you will allocate a lot of objects. And then propose the action to all your kind of soldiers in this game. So soldiers are in this case buildings and scripts which are small robots that can move energy around, can fight with each other and so on. So this is actually a very good programming game. I do recommend it to people that want to learn JavaScript or want to learn any language that can be compiled to JavaScript and put on somebody else's node server. It is good because it has a rather complex economy so there is a lot of interesting things to start programming with and you can do pathfinding your own because of course game's pathfinding is a little bit inefficient and large scale. So the curve is rather smooth. So you start by using the game's pathfinding and then you find it inefficient, you improve on that. There are a lot of algorithms you can write. If you do a lot of complex interactions, I would say JavaScript is not the most efficient language for making a complex algorithmic curve. You need something like flow or something like TypeScript to check the types. You need something for testing. So there is actually a guy who produced just for this game a whole unit testing framework that fakes all the objects in the game AI that are queried by game AI. So all objects that are presented by the server to the game AI so that you can do unit testing of your AI. And there are a few thousands of players that write AI that play this game. So the community is rather large for a programming game. So that also means that there is competition between algorithms when people start using very, very interesting strategies. So potentially the possibilities are quite large and that means that your code base will grow. When I finished the last iteration of my AI, that was like, I don't know, 7,000 lines of code also. Without API from PureScript to JavaScript, of course. And what you see is also this type system really helps. So what PureScript also has is the type system with type classes. There are basically groups of types that have the same interface. And you can have between type classes, you can have this kind of inheritance basically means that if for example you have an object that is structured and you know that it has property, has ID, has unique ID because every object of this kind has also unique ID. It is structural which in this case is the class for having things that are having a number of hits and fixed position on the map. And it is a room object, sorry, that's a room object quality. That's fixed position on the map. And hits, that's structural. So we can use this type classes to model, you know, that the functions have certain groups of objects that are not necessarily the same, that have the same interface. And that's very common for most JavaScript frameworks. So if it's large enough it will need something like type classes. And because it's JavaScript and people feel very elastic about adding the function with the same name with the same type signature or the same behavior to the objects that are totally different. So having a way to model this besides union types is very useful. That's also something I would dream to see in the future. That would be great. But for now I have to subside and use PureScript. And I'm pretty happy with PureScript. I mean, it's very, very efficient for the map. The only thing is, I mean, as I told, we are hiring. We need people that know PureScript. Or Elm, really. And here is an example of how simple it is to make API. So I found it's like one of the languages that have the simplest way of making API. If you know both JavaScript and PureScript. From this example, you immediately know how to make a constant. So basically you have, say, two files, API.js and API.pours. And PureScript file normally declares your code. It describes your code, contains your code. And in this case, if you declare something foreign, it only contains the type. That's totally sufficient. Only type of the object. That means foreign function interface. So you declare the type that you find fitting. And then in API.js, you just declare the function. The only thing that you need to make is that, first, you put it in exports. So this will be the constant. So the value is really directly translated. The second thing is that for the function, you need to create. So only one argument at the time. That's very simple. That actually can be helped with functions that are very polymorphic and just convert the functions that have four arguments into basically element-wise. And again, I would say that's good when you know and have discipline to correctly cut the corners. Because if you cut the corners, yes? So then you write? Only if you treat it as a foreign object. So basically any object that is marked with a star in FFI can be anything. Or you can declare the type for this object. This you can also declare in FFI. You can declare any new type for the object. And it's kind of opaque. And then you would have to have apply function that applies to four arguments functions, three arguments functions. That will be a little bit inconvenient. Yeah. I hear that there was a company that made an extension of PureScript compiler that did only one thing for optimization of PureScript, which is basically automatically uncurring and carrying function in the compiler. That gave them a huge boon to the efficiency. And I would hope to see this optimization in mainstream PureScript compiler. Unfortunately, to my knowledge, it's not yet matched. But yes, this could be solved with a very clever compiler. And authors of PureScript do not prioritize that. But they prefer to solve it with a compiler than to make some other tricks to do it. Because as of now, it's me. I mean, it allocates a few functions possibly. And you may have a problem with it if you try to make a very, very low location count JavaScript. But otherwise, it's efficient enough. What does PureScript know that takes to live is safe? All it knows here is that VAL is specialized to be us. VAL is a string. But it doesn't know what object it is. It doesn't. If you declare foreign function interface incorrectly, you can get a JavaScript error. So technically, text to live is not safe? Safe means that since I know the type of text to live, using of this function is safe for the programmer that trusts the FFI. This is unsafe because here, even if you trust the FFI, exposing this function can totally screw you. Because it stops checking in a way. Because it makes the function type too polymorphic. It's sometimes useful, but it's not to be exposed to the end user. Sometimes what you want are levels of unsafety or safety. Sometimes the highest level of safety is you have automatically proven verified compiler. The next level would be strong type system and only doing what is allowed by strong type system. But there are lower levels of safety, which basically means I trust that I examine this 100 lines of code of API that conforms to the JavaScript API, but my 7,000 lines of code don't need to be checked anymore. Because if this 100 is good, then the other things are also good. So you decrease the surface of the possible bug appearance. I would say if you are able to even divide your code somehow, like 80% or 90% code will contain much less errors because of strong types. Because this is given. That's already 10 times less bugs. That's an important thing. When you use FFI and implementation in JavaScript is wrong, then nothing saves you. That's the penalty or risk for using FFI. To be honest, if you are using a compiler and there is a bug compiler, then nothing ever saves you either. It's just that you have much more trust in the compiler like PureScript that is used by so many people already and that has been used to compile so many programs. You prefer to defer some checking to the compiler rather than your own eyes. So the safety is in this case about how much of the code you need to examine to find certain kinds of bugs. You use it mostly to interface with JavaScript library, right? Yeah. So I mean, JavaScript library are known to be not safe because... Yes, but if you want to use the JavaScript library, that's the design constraint. You want to play scripts with strongly typed language. The only way is to use the servers interface, the AI interface, AI API, that is already in JavaScript. They don't provide the PureScript API. So what do you do about it? You make FFI binding and hopefully you share the code with other guys that they will test it. So there are ways to work around this. You could say that Dell also uses this in a sense, right? Yeah. Libraries in the official package network that uses the unofficial FFI in the sense that they contain some of the JavaScript code along the same lines that we have described that has been reviewed by multiple people that have proved the project. But you as a single user cannot publish packages that use this kind of method because currently, you know, there's no system of showing that level of unsafeness or whatever and probably never will, right? And that's also why even though you can do stuff like this for your own code in your own project, not sharing with anybody, there is no official documentation on there for FFI because it may change. It's not a supported interface. There is a different way to report, which is the official and safeguarded in and out of the runtime, but it is viewed in some of the standard package stuff. Yeah. Before I get to that, I share the same question with you yesterday. Like, depends on how you define the state, right? If you're talking about, like, passive division, like, there's no runtime error, you call this function, then this function might not be safe because when you call to level 5, it might fail runtime. But if you talk in terms of, like, the level of emptiness, and I guess, or if you define safety as, like, something that's level lower than type safety, then you can see that it is... It's a contract. Yeah, it's a contract. Yeah, it's enforced contract. It's not just, yeah. So, like... Just not any. It's enforced by the compiler. So, that's kind of summary. I think I did something... Oh, it's still cut. Okay. So, here I see both solutions having really great advantages. So, Elm is more robust because, you know, you have this limited number of packages that can use any unsafe constructs. Thus, it is, you know, better reviewed. On the other hand, PureSkip is elastic in this way. You can just put the FFI and, you know, kick FFI in a few days if you need it. And sometimes it is advantage. If you know FFI will be small, my project will be big compared to this. You probably want to go with this. Yeah. Because it's still better than using PureJavascript. Yeah. And for some people, it's definitely better than using TypeScript. I would say Elm still has great advantage in very elegant modeling of state. So, there are PureSkip libraries for modeling the state. But I have yet to see to find something as elegant as modern views in Elm. Yeah. There are very similar libraries actually in PureSkip. But the reveal is in details. Yeah. I would say also there is very, very coherent vision in Elm. In case of time, in PureSkip, you have a lot of authors and the package database is like very open, very embracing. And sometimes these packages are incoherent. Groups of people. Yeah. It's a group of people that evolves the language and pushes it together. It's relatively small and relatively well communicated. But it's more than one person. Is it still evolving language-wise? Yes. It is evolving slower and slower. But certain features that are being asked for like existential types or something like this, rank to polymorphism are definitely very low priority. Or even integration of this optimization for carrying. But yes, it is evolving. So, they try to keep up with Haskell feature-wise. You see frequently the changes that match the syntax of PureSkip and Haskell. But the code is incompatible. Just look at EFF monad. That's very incompatible change. Something you've been doing in PureSkip that you can't do? Do they have features that are not? Sorry, that was a slide. I don't remember exactly. There was one or two Quicks of type system that are actually very specific to PureSkip. But I looked at them and then I forgot about them. I'm not sure they are still there. Because authors tend to try to go after the Haskell in terms of features of type system. I'm starting to use a lot of Haskell and PureSkip. And told me from his beginner point of view that PureSkip mostly got the good ideas from Haskell and removes the things that should change like I.O. is taking everything in Haskell and they are separated in a way that you specify every effect that happens. Yes, so there are these differences. Definitely there are things like lists that don't have special syntax in PureSkip, for example. So you need to say cons and the needle instead of operators. But it is very similar. So there is a company that uses PureSkip heavily for their websites. I forgot the name now. I think it's one of them is CDN company and the other is... Oh, I don't want to lie. So I would advise you to check on the website to learn the specific names of the companies. To my believe they are users. They are kind of poor users. And they feel it beneficial for them to support their platform. Yeah, I think it's in a way... So it's not a project like Flow, it's more a project like React. So it's not an internal company project that has come open source or a project made by a specific company that is open source by accident. It's more like the company supports the platform and there is more than one company. So we build on this platform, thus we give back. I have a generic question for when a company... Because as techies we have all sorts of reasons to try new things and put it in our projects. What would make a company, the stakeholders, adopt what they see as belonging to the platform like PureSkip and Elm? Because when you talk to a... I think you underestimate the power of meritocracy. Because companies are in a way entities like people that have their goals and they want to realize it as soon as possible, usually, as well as possible. And from the point of view of the company, like any entity, it may be beneficial to do it. What I understand may happen is sometimes the companies exhibit either environmental constraint or organizational resistance. Environmental constraint is like how many programmers I can have that will program in PureSkip. And as you see with Elm, people catch up very fast. And our level of technology knowledge is increasing and our requirements are increasing but people are expecting to learn more in any tech job. So this barrier of knowledge is really rapidly decreasing. You see people catch up new languages faster, thus remove other barriers for them, technical ones. On the other hand, there may be organizational constraint. This is a very popular thing. Some of the clients of the company only want Java or some of the people in the company don't trust any platform that does not have backing of big company. And this is also changing because we have a lot of platforms, a lot of technical solutions that are moving forward specifically because new companies choose their platforms. I understand that GitHub, for example, is mostly built on rails. And you see, since these companies are rapidly gaining traction, that means that it's basically fitness criteria. You see companies that use new technologies that may be small initially, like PureSkip or I don't know, gain traction. Or Haskell was. And now, or Standard Chat uses a lot of Haskell. They have their own computing pilot. And you see these companies gain traction. They find it cheaper to use certain kinds of solutions. They will use more of these types of solutions. So then it means the other companies will try to compete them. And the same with Linux. Initially there was just one or two companies on the stock market that uses Linux. Now everybody does. Because it's fitness. It's the ability to reach your goals that you want to reach against both technical and non-technical constraints. I think it's also interesting to know that, for example, Noready is saying that since the shift to Elm, there are a lot more attractive. They recruit better programmers in this shift. But they think you must not have to constrain from your organization. If your clients are just in your results, then what are you thinking? Yeah, if it's a programming and service company that will work better when you're building a product stack on their own, there are more considerations about why... In a way, I wanted to move people from Scala to Elixir and from Java to whatever Angular to something else. It's complicated. There is also an audience in it where they announced that there was a person who should be cooking in the language. There is one in India who from the minimum working aspect. They were explaining how they tried to introduce cooking in their company and what were all the errors to be made in the list because... I think at the end of the day, it's the effort for experimentation as well. Obviously, people are interested in the standard language, but if you as an organization doesn't tolerate that kind of risk, then it's not going to be worth a lot of effort. You looked at switching from Scala to Elixir. At our company, we're looking at Elixir as well. So far, it's just field experimentation. We haven't really found the right project to do it, but people are interested in doing it. There is one, and we're more than happy to go ahead and do it. If you say people in the company think that, oh, I don't think we're ready for it, and you never think that risk, then in the end, you'll remember that. I agree with you on this one, that I think it's not going to be long before the tables are going to flip in that sense that your question will be, do you still risk using JavaScript in its regular sense? Right now, it's not a risk because everybody is doing it. Not for big applications. Why are you choosing the less safe option, the less productive option of staying in there? It's not there yet, but I think we're going to see more and more make that switch in the coming years. Do you have anything else? No, thank you.