 So, now the next talk, an overview of non-mainstream languages about parallel programming. So, Lens, where are you, Lens? Well, you all know that when in this sort of conferences you are requested to write a short bio, and we all know that it's the person that writes it, not the other. But I love the first and the last sentence of Lens, so he starts saying that Lens is a true geek. So, which is not a big thing here, but what I love is the last sentence. We say Lens likes Pearl, Erlang, and life in New Zealand, which it's something that for, how can I say, a guy coming from Germany two, three years ago, it's a nice change. Lens, it's also runs the functional programming group in Wellington. It's a strong interest in concurrent programming, as always on the loop for the optimal tool for the job. So, we work together in an open parallel, which is a small consultancy shop that we started a few months ago. But he was previously the CTO of United Domains in Germany and Technical Director at Lycos Europe. And you're ready to go. So, please welcome Lens. Okay, so... Okay, you hear me? All good? Sweet. Yeah, so I'm between you and the coffee break. Hope you bear with me for a while. I talk about surprisingly parallel programming, but you've heard a lot about parallel programming today and I don't want to bore you with other special aspects of how do you do your memory management and things. I'd much rather like you to take you on a journey through a couple of different ways how to actually do parallel programming. And I'll probably start briefly with how I learned parallel programming, which has nothing to do with nice CPUs and shiny threads and shiny languages and all that. It was pretty plain, simple internet business. We had a lot of people hammering our website and we had to scale that shit. And it was awful because the stuff we came up with was horrible. We used databases as message queues. We did a lot of PHP stuff that didn't scale really well. We had front ends that were mangled into the back ends and it was horrible. It was typical .com startup code that no one wants to look into it. So I came up with my kind of back end thing that scaled roughly and moved into a small message passing environment and was all written in really, really nice Perl at that time. Communicated with my nice PHP stuff in the front end through databases and message. Anyway, it was a really, really rough journey. But what I learned out of it was you can scale that stuff and you can kind of come up with interesting concepts. But the longer you dig, the more you actually realize that someone else has been there before. And I stumbled upon Erlang which is a really, really nice message passing environment. And Erlang is a language that comes out of Telco. It's specially designed for concurrency of something that is network bound ideally. And it just kind of opened my eyes and was, hey, probably I should have looked around a bit more instead of just ran off and thought I know it. And this is what I'll take you on a journey today through a couple of different languages. It might be interesting for you to not run off into a certain direction and kind of hit your wall against, hit your head against the wall and just kind of try to solve something that's been solved a couple of times already in other languages. Just briefly, I want to talk quite a bit about functional programming because that's kind of one of my passions. I'll talk briefly about high performance computing systems. And I have two languages that I'm a bit more passionate about as well. I kind of want to stress to you as well. But they're kind of old school, really old school. Another thing, I'm not a pro in all the languages I'm showing you today. I'm a Pearl hacker. I'm an Urling guy. I know a lot about functional programming languages because I run a functional programming user group in Wellington. But please feel free to shout out and kind of tell me more about the languages that I have up here. I think some of you might be better than me in a lot of the languages up there. But before we dig into that, I kind of want to just raise the thing that knowing one language doesn't really help you. If you learn more than one language, it also teaches you to think in a different way. Like, I'm a Bavarian originally. And beer is something that is kind of one of our base nutrition. And it's really something we grew up with from small. But something I really only learned in New Zealand was that you actually drink lots of beer to get wasted. And that's the only purpose. You don't drink it because you like it. And that was a different mentality that I learned. And every language tells you not only the words, it also tells you a mentality. It also tells you a different way of looking at things. And this is why I think functional programming languages especially are very, very important to know at least one. Just because it bends your mind around what computing can be other than declarative kind of going top to bottom. This is a very small kind of selection of functional programming languages mainly, not only, that I want to go over today. And I try to come up with a graph of influences, like which languages kind of influence the other ones. And we'll come back to that one later in the talk. But one of the languages you see at a very kind of high level is Lisp. And Lisp is important. Because Lisp was kind of the first real high level language that tried to come up with high level concepts other than just kind of plain assembly. And it's only I think the second oldest high level language other than Fortran, which was I think a year earlier, but correct me on that one. Okay, sorry, third. I'm too young for that. It was written by John McCarthy on the MIT, has a big strong background in artificial intelligence research. And I think it's an interesting approach to write languages and it's such a simple concept that a lot of Lisp dialects got implemented in other bigger programs and languages just as a kind of a subset. One of the interesting things as well is the Lisp guys always thought that memory management is way too precious to leave it to the user. So they implemented a garbage collector right away. And this is very different to all the sea guys who think it's way too precious to leave it to a machine. So they're really kind of... But that makes Lisp very, very easy to kind of start wrapping your head around as well. You don't have to worry about memory management. You just kind of get going. And to give you an idea how Lisp looks like, and yes this is one of the biggest critiques of Lisp, all the brackets at the back. Never forget one, you need an editor that actually highlights it. But if you look at it, it's very simple. If you look at the innermost bracketed things, you have a function in the beginning and then arguments that just apply to that function. So it is from the notation to learn, it is actually pretty straightforward. Any questions about Lisp? Don't hammer me with it. The second very important language I think is ML. ML influenced a lot of other functional programming languages and it's not as old as Lisp but it's from the 70s and was designed for research purposes mainly for proving mathematical things, for proving functions. And it's called ML meta language. And it has this garbage collected as well. It's a theme you will probably notice throughout a lot of the functional programming languages that they kind of have used to manual memory management. They like to hand it off to some automatic thing. And ML has a very different kind of notation. So standard ML kind of looks like. And if you look at that notation and keep it in mind for later slides, there's a very, very dense notation, a very short one. ML is kind of died out but its main uses today is standard ML or a camel. And standard ML is kind of more in the research area. And camel itself was originally implemented in Lisp and was known for its resource greed mainly. And then some guys said, okay, we like camel but the resources it needs is just ridiculous. So they rewrote it in C and came up with camel light. And that kind of morphed in the meantime into camel, more or less. And camel is probably the camel dialect that you want to pick if you've never picked up one of those ones. Probably camel is the one you should start with. And the syntax looks pretty much the same. It still looks like ML. It has, okay, camel has more syntactic sugar around it. It has objects. It has more volume to the language. One language that is very, very similar and I kind of, I'm not sure if I should present that one here today, is F sharp. F sharp is nearly compatible to camel. And it's the Microsoft kind of way of, this is how functional programming works, comes out of Microsoft research was built in kind of around 2002. And it's really the Microsoft approach of including something in the .NET environment that can deal with functional programming. I think it's an interesting development because this strange F sharp thing drove a lot of guys to my functional programming user group. They suddenly have this in their .NET thing and they don't know what it is and they kind of get curious about functional programming. And I think this is an important thing or development because it just raises awareness about anything. There is something beyond C sharp in that case or .NET which is horrible enough. And it's, F sharp is kind of, knows both worlds. It is functional. You can use functional programming concepts but you can also use object oriented programs concepts and you can blend it with C sharp if you want to. This is roughly how it looks like and heavily, yeah, looks a bit like, like a camel. The next one I want to briefly talk about is Erlang. Erlang is a special passion of mine. It's an interesting functional programming language as it is a pure message passing environment. It has a shared nothing architecture. You can't really, if you try really hard you can write code that interferes with each other but it is normally really strictly encapsulated. Every process you spawn is on its own and the only way to communicate between all those processes is by passing messages around. And this makes Erlang a very interesting language to scale. It literally doesn't make a difference if you run your code base on one virtual machine or on one virtual machine or on several virtual machines on one physical machine or on like 200 physical machines across the globe. Erlang doesn't care. As long as those machines can see each other it will just magically kind of work together. And the Erlang virtual machine that interprets the Erlang bytecode is really a nicely threaded application in the meantime that can scale linear to I think they're about around 32 cores in the moment but they're working on even better scalability. So if you're talking about a lot of a lot of concurrent Erlang processes which are not one-to-one to operate in system processes and you have a lot of CPUs you can definitely make use of the Erlang VM. The Erlang is normally bad is if you have a small problem and it is one thread and you just number current something small or so you can't parallelize it. Then Erlang is always worse than all the other nice languages but if you have a big problem with a lot of network sockets for example or with a lot of things where you can do a lot in parallel Erlang is often outperforming a lot of other languages. This is how Erlang looks like. Also quite dense syntax. The syntax is one of the biggest critiques for Erlang and it is kind of awkward for the first time and it has all kind of those weird concepts like single assignment. You can't change a variable once you have assigned something to it and they come up with all those explanations why it is good. It is awkward when you start using Erlang but once you wrap your head around it it is very very easy to read code so after probably a week learning Erlang you will be easily capable of just reading pretty much any Erlang library and you understand it which makes it really a nice language to learn and a nice language to to get going with and the concepts are different enough that you learn something different. Yes it is a recursion is kind of the default thing that you do in pretty much any functional programming language. Yeah it is tele-recursive and it has higher order functions so you can treat functions as data. You can do all those nice things that you do in other functional programming languages. You can. Yeah but it's if you you can even write code with side effects if you want to. If you try really really hard you can you can do that and for some things it is it is important that you can but the language is designed around side effect free code and those whole comparisons between languages are normally tailored towards one specific problem space. If you design a language shoot out around writing a web server I'm pretty sure there are other languages succeeding than if you design a language shoot out around crunching an algorithm than if you design a language shoot out around. So I don't give too much about those numbers that come out of those competitions because they normally dissolve the the image of a language because you really try hard to tailor your code towards exactly this problem but a language is way more than fixing one specific problem I think. Haskell. Haskell is another very important functional programming language that kind of struggles to get out of this research notion that it is in. It's very very often taught at universities and kind of struggles to get into the real-life coding world but they're actually doing quite some work in a moment around threading and about a multi-threaded Haskell compiler and there is some some interesting support by the Haskell guys to get real world implementations that are really large and they kind of to demo the the threaded implementations they have of Haskell to to demo them to a to a larger audience and Haskell is in an interesting language in that respect that it's a pure language so it is it is side effect free it is lazy in evaluation it is kind of always trying to to to go as fast as as far as you can with without evaluating all your or your code and it has a very very mighty type type system that makes it an interesting experience to program in in in in Haskell I think to show you briefly what I mean is this is how you would define a function which means you not only define a function you also define a function plus the types that are expected as inputs and outputs in the in the type system and then you use the function and define actually the function and there are two different implementations in fact there for most of the languages I really just put up one possible implementation of the factorial but there are there for most languages different ways to to to write it but for Haskell I thought those two are so so different and the second one is showing the list processing that is so fundamental to all the functional programming languages so nicely that I put it up as well so this is this is a way how how Haskell looks like and I think it's a it's a very clear and a very interesting way to to define things the next one I want to go into because it is really gaining popularity because some of the web2go startups not so much startups anymore like twitter and so on they started using Scala Scala is really kind of rising up on on in popularity I think especially because there are all those frustrated Java guys that try to do some code that doesn't wear out the nothing so much and they they are all kind of keen to to program in a way that sucks a bit less I think Scala is one of those approaches runs in the JVM and has a quite quite tight integration between Java and Scala and it really tries to to bring functional programming to to the Java community in a in a way that that we haven't seen before and I know I know a lot of functional programming guys that are forced to work in some corporate environments and they have to to to develop on the JVM they have to work with a lot of already existing Java libraries and they are all really really attracted to Scala because they can write in a functional way but without having to rewrite all this legacy code that is around already so they can just tie in those libraries using from within Scala in a in a functional way and I've seen a quite a bit of of interest from from the Java community that realize that there are those awkward functional programming guys that do some weird stuff and Scala seems interesting and they suddenly show up in my user groups and are interested in functional programming in general so I think Scala looks really promising and I think is a is a important language but on the other side if you look at that factorial well honestly if I look at other functional programming languages I mean looking from a Java point of view it's it's fine it's dense it's it's not too two verbose but looking from a yeah there is another interesting language that showed up in the last couple of years which is closure it's also running on the JVM but comes from a totally different angle closure doesn't try to be a better Java closure really tries to just use the JVM as a VM and then do in fact list on top of it so closure is really just a list kind of dialect actually a pretty pretty close to this dialect that runs on the JVM and has some sort of macros that can tie in Java libraries but it is not as convenient as Scala and this is not something that I've seen so much interest from from the actual Java community I've seen quite some interest from the from the functional programming guys that try to write lists on the JVM but the Java community is more biased towards the Scala language than to closure and this is how closure looks like it's pretty pretty much as you would expect it the last language that I find quite interesting is a very very young language that just came up I think they they announced somewhere in autumn last year but they're actually there and they're alive it's a language that comes out of the Mozilla from from some Mozilla guys and they try to come up with a programming language that is easy to write that is easy to write bug-free code basically really really try to write the language in a way that you can't corrupt memory and that on a multi-core system and multi-operating system so they they develop on linux os x and windows in the moment they develop on four plus core machines and they try to come up with a general purpose programming language that it is easy to to understand easy to write and really really really hard to fuck up basically so it is an interesting concept but it is very very really stages they have a working implementation but they are still far from from being a language that is complete as a language but rust looks very very promising and if you want to play around with something really new and really cutting edge I think rust is something you should look into this is how rust code looks like and the lower part is how you would actually implement actually call it and the guys are really really active they are really heavily developing on the language in the moment and it is certainly something worth watching yeah compiler has to figure out I think okay break we made it through the functional languages um off to sorry before you continue was a question oh sorry in the bag oh okay we can I haven't looked too much into closure I'm not so much a jvm fan that's my whole problem can you give him the microphone just a moment so I don't have to repeat everything so it's about the parallel features in the closure engine yeah um closure is also designed from the ground up to be a parallel programming language language they use um stm shared transactional memory approach to concurrency and all of the data structures in closure are very carefully written to be immutable and yet efficiently updateable so you can make a copy but it's kind of a shallow copy and then you can kind of update just a little bits that you've changed so let's you not have shared state but not be horribly inefficient at the same time and they have an they take an approach like database servers do where a number of threads can be trying to modify different things in transactions and basically the first one to finish succeeds and all the other ones just retry stm is a is an interesting memory management concept for the ones that have you how many of you know stm okay so big trunk so stm basically treats or in a very very simplified way stm is is memory treated as a as a database that has transactions um and you simply transform transactions or perform transactions on on the on the memory and you can roll them back and um and the Haskell has some some support for stm um only for for pure code not for code that has side effects like you couldn't use it in in monads that actually have IO interference or something like that so it is part of part of the Haskell functionality if you if you treat or if you take the the right subset of the language it's used in a couple of other ones uh skm is certainly interesting because it doesn't lead you to corrupt your your memory so easy the other way is just um to use message passing like urling that uh does um to get around the total shared shared memory and locking issue um you can actually use stm with IO actions you just need to write your own rollback hooks so you need to write your own unfired the missiles if you're going to use fire the missiles in a transaction okay just in case you have to roll back anything else for oh okay sorry you mentioned rust which is fairly immature language but a language which is also very new but uh much more mature than rust but in a similar vein is go and i wanted if you'd looked at that and if you had any thoughts on that um go is interesting um go is go is kind of or google is kind of big enough to push go but honestly i haven't seen too much uptake in the communities i am in so this is why i haven't included it but included rust which definitely has no community uptake in the moment because it's really really new but go is go is an interesting approach but i'm honestly not sure which gap it's trying to fill because for the problem space go is trying to to run into and or trying to to fill um there are a couple of other languages that already have a bigger community around it and i i haven't seen any substantial project within google using go so why would i need to look into it kind of i don't see the need for it really i think there is well i think go is in the same space like a couple of those traviem basements like like scala for example i think scala is a strong a strong reason to not look into go and from from the other end it's f sharp because the corporate guys they they're really kind of looking for something that has big ide support that has big companies behind it well google is big but not in in a way of writing languages so i'm i'm not sure which which is the niche for for go really in the moment a huge distinction between those two languages go and i get into something later on in the talk that probably is another so it's um we still have five seven minutes there's a question there or i have more slides please so continue then we go question thank you okay um i wanted to quickly go into the higher performance i have productivity computing systems which was a challenge by dapper started in 2002 to find the next big language we're all writing in um that was basically an open challenge to a couple of big guys in the in the in the computing world to come up with a language that is easy to write for research researchers and probably the military um that is fast enough to complete problems in uh in an endless time and um that scales really nicely to many many cpu's possibly thousands um to run on big machines so that was kind of the the cornerstones dapper put out and um the the three main companies that kind of survived the first and second round were ibm sun and kray ibm with a language called x10 um sun with a language called fortress and kray with a language called chapel and kray dropped out the next sun dropped out the next so we are left with ibm and um ibm's x10 is kind of an interesting thing that goes into the go direction as it is it has basically two compiler backends it is either running on the jvm or it can compile down to c++ and then to native code and um it is written in a way that it is possible to actually add more more backends if needed and the idea behind behind x10 is to to have a language that is really really simple for researchers but also that you can write it basically or develop it on your on your machine with the jvm backend easy to set up easy to hook into an ide and so on and then if you need it to scale you just push it through the other backend and you actually get proper code that scales nicely um and if ibm succeeds the next couple of years we're all programming in x10 in a year or two or five or never and um we will all write this nice new language it's basically a hybrid between Java and a couple of other ideas on how to write a a language um one interesting thing of uh how they got to got around the locking issues that you have in multi multi in parallel programming is that for parent child locking mechanisms so you basically tell a parent you're doing this job the parent spawns and amounts of childs and a child can never lock a parent but only a parent can lock a child so this is how they try to to solve the locking issue and um yeah DARPA thinks that ibm did it with x10 let's see where if we hear about x10 in the next couple of years um the next one is the other one is fortress from sun i think we're running out of time um it's basically the concepts of Fortran um blended with um a syntax of Scala, Haskell kind of and um the the interesting thing that i think about fortress was that sun went out and said okay we have researchers they are normally used to see formulas and things and we are actually developers we are used to write functions and things so they have different style sheets to display the code so you can either write a textual representation of signers x and so on or you can put on another style sheet on the code base and then it just does um render it as as mathematical functions and so on so that's the thing it's a pretty pretty smart thing but yeah they lost out against ibm and uh no i think the the project's actually open source or actually didn't kill it yet so should be somewhere available it was open source in 2007 or something later and just briefly we have reborn this one raw vm came out of the ibm research um lab is actually a small talk vm quite interesting to look into if you're into object oriented things this one's actually tailored towards many core processes and is a another approach of ibm to tackling the many core problems um this is how victoria looks like and then we have one undead that i would really love to see coming up we have seen lisp coming up i would love to see prologue coming up again it's kind of forgotten but not really it's still around and there is threaded implementations of prologue and this is roughly how victoria looks like that's it so it's uh right on time so well done for that i believe that lens will be more than happy to take all the questions at the same time it's time for coffee so no one will say please don't go because you are allowed to go but question time please coffee time question time sorry i am hello just a really quick one lens one probably the most widely used language in the world which has higher order functions as javascript it's not in your list no i know um and i'm sorry about it javascript is really really interesting sorry about that now actually javascript is in that respect really interesting as um the whole no j s hype that comes up in a moment makes it really interesting um to watch all those guys jumping onto javascript now and yeah we can use javascript on a server and then in the same moment realizing fuck it's one thread well no j s is really a newcomer like there's been a jvm based server side javascript since 2000 called rhino now it's called ringo that's multi-threaded and it runs reasonably on a jvm like collusion or the other jvm languages so yeah i think the hype about no j s is a bit funny too since there's lots of there are so many cores are exploding and they're building something that only runs on one core yeah and there are so many solutions out there but it is really so often in this wonderful web industry but someone comes up with something that we've seen already five years ago and it actually works and some guys are using it and he's just using this tiny little subset of it and it's yes go for it and the whole world goes crazy and then they realize damn it's actually implementing problems that we've solved five years ago already so no j s is a typically example just a comment that that's i have to say but introducing any programming language is so stupid yeah yeah so actually a lot we have we have lots of those yeah uh just another quick comment because i don't think it was mentioned our scala also has does scm um like cascal and closure but scala it's not all scala's data structures are immutable so you have to watch out because if you use one that is mutable you kind of unless you lock it inside a reference you yeah it can it can cross the transit outside of the transaction you can mutate it outside of the transactions which is kind of bad yeah yeah the problem with scala and stm is also but if you're hooking in uh travel libraries they do memory management in a different way so exactly that's that's the issue where you kind of have to look or watch out for okay okay thank you very much everyone please come back