Archive

This is one of the last interviews I made to the speakers of Erlang Factory London 2011. One of my favourite erlang developers is Michal Ptaszek. Michal works at Erlang Solutions Ltd in Krakow. He is pretty famous among ejabberd developers and XMPP lovers.

Ask and Aswer

Paolo – Michal, can you introduce yourself to our readers? Michal – Hello, I am Michal Ptaszek – Erlang passionate and evangelist, someone who became seduced by the beauty of logic of maths and algorithms in his early childhood. Currently I work for Erlang Solutions, trying to cope with the complexity of massive scale Internet Messaging systems. From personal perspective, I have done my masters in Krakow University of Science and Technology in Grid systems field (Erlang obviously!), currently I live in Krakow, Poland, love jazz and modern literature (especially latin). Some day would like to find some time to learn how to play sax.

Paolo –How did you “discover” Erlang? Michal – It has started in the early 2008, when Joe Armstrong came to Poland to give a talk on Erlang concepts for Student’s IT Festival. Of course almost no one has ever heard of the language (or. even if, never touched it), and as Joe is such a great speaker, he planted some seeds of curiosity in my mind.

Paolo – How long did it take to you to master Erlang? Michal – I wouldn’t say I’ve mastered Erlang. Comparing to such people as Ulf Wiger or Robert Virding, I’m still in my infancy 🙂 The great thing in Erlang is that you do not have tons of code everywhere: language is simple, standard libraries are manageable, even VM: if you clench your fists you can read and understand the entire code in few weeks. In my opinion people are in never-ending continuos process of developing themselves: when I look at my code written a year/two ago I feel ashamed of myself and would love to throw it away and rewrite it in some nicer way. I guess at the time when I discover there is nothing to improve I will be forced to change the profession (or at least the programming language) 😉

Paolo – How did you find your first Erlang related job? Michal – Few months later after Joe’s visit to Poland, Erlang Solutions (Erlang Training and Consulting back then) decided to open an office in Krakow: I did not hesitate a lot and applied for the internships. The office grew from 3 to 12 people since then and is extending all the time: I guess it was a really good choice.

Paolo – What are the things you love most of Erlang? Michal – Just to name two most important things: – built-in parallelism and distribution – I can not even imagine how do people distribute their applications and protect their critical sections using semaphores and mutexes. It’s so 1990… – fault tolerance – one of the least appreciated things in the language: ability to isolate the errors, propagate them in the controlled way and recover automatically. In the systems that run on top of tens/hundreds of machines crash of one of them is not a question of ‘if’ but ‘when’.

Paolo – During Erlang Factory, you will talk about Erlang and XMPP: can you give to our readers a brief description of your course? Michal – Yes, together with Michal Slaski we are going to teach a one day course on Erlang and XMPP (ejabberd in particular). During those few hours we would like to show how the things work under ejabberd’s hood, why it is not a best idea to keep the default configuration, what are the low hanging fruits for ejabberd, BEAM and OS enhancements, how can we monitor existing server, how to cluster several daemons together in one command and finally: what are the ways to extend the functionality programmatically.

Paolo – Who should follow your course and why? Michal – Definitely people who are interested in Internet Messaging, even not necessarily in XMPP. Architecture of message/presence router, as well as the easiness of extending current functionality, federating with other protocols or finally scalability might be stimulative to someone who plans to set up a startup or replace his current messaging server with something better.

Paolo – Why should an XMPP programmer use Erlang as development language? Michal – Mostly because of the concurrency and scalability. Erlang actor process model fits perfectly in the concept of independent user sessions and communicating with each other using asynchronous message passing.

Paolo – In your opinion, what is the most important thing to keep in mind when developing with Erlang and XMPP? Michal – Global state/shared data is a root of all evil. The less things you share – the better you can scale. XMPP systems have tendencies to grow rapidly: it’s basically the linear relation to the number of simultaneously connected users. Shared global state will not pop up as a bottleneck until it is too late: when users are storming our gates and we realize that things should have been done in a different way long time ago. And there is also one more rule, that people often forget about: KISS. IM systems are really simple, let’s do not overengineer them

Paolo – Can you recommend to our readers some books, sites, or blogs that will help them in the world of Erlang and XMPP? Michal – Definitely take a look at Jack Moffitt’s both book (“Professional XMPP Programming”) and webiste(http://metajack.im/). Another worth-reading blog is Stefan Strigler’s http://blog.jwchat.org/. To be honest: there is still no book on Erlang and XMPP in particular. Maybe it is a good time to change it? 🙂

Today I will have the chance to interview Robert Virding. Robert is not only one of the speakers of Erlang Factory London 2011; he is a co-inventor of Erlang (we all should thank him for writing a lot of the libraries). Robert today works at Erlang Solution LTD.

Ask and Answer

Paolo– Can you tell us something about yourself we can’t find in the Internet?Robert – My father worked for SKF, a large Swedish corporation, and had been stationed overseas for many years, first in India and then in Australia. I was born in Bombay (it was called Bombay in those days) and then grew up in Melbourne, Australia. It was not until I started university in Uppsala that I moved “back” to Sweden.

Paolo – I heard that your educational background was focused on Physics, how did you end up to programming?Robert – Yes, I was a physicist and had never really been interested in computers or programming. The physics department got its own computer and as I was a post-graduate I had more or less unlimited access it. This very quickly led to me starting to program and learn various programming languages. I did some programming for the physics department converting old lab programs to the new system. It very quickly became my primary interest and after a while the physics department and I agreed that it would the best thing for me to try and find a job programming. I then got a job at Ericsson in a small group managing VAX/VMS computers in the Stockholm region. While there I amused myself with porting Franz Lisp from Berkeley Unix to VAX/VMS. The computer science lab then asked me to join them, which I did and I remained there until I left Ericsson in 1999.

Paolo – What was your main programming language before you started with Erlang?Robert – I had programmed in a number of different languages before Erlang depending on my interests and what I was working with at the time. So at the physics department it was some Basic, then mainly Fortran and Pascal and some assembler and C. At Ericsson it was initially more Pascal and C and Lisp. At the computer science lab I continued using Lisp, and then Prolog and a number of concurrent logic languages like Parlog and Strand. As I was also implementing these languages there was a lot of C programming as well. We also did some work with Smalltalk and functional languages other than Erlang.

Paolo –How does it feel to be one of the fathers of Erlang?Robert – It is quite exciting now, especially seeing how it has spread into areas other than we originally were looking at, some which hardly even existed at the time.

Paolo – What was the most difficult problem you had to face when designing Erlang?Robert – “Old sins cast long shadows”. I think it was the realisation later on how hard it is to change something once it has been released. For some parts of the Erlang language and environment we spent a lot of time trying to work out and test the best way of doing things. Other parts “just happened” when someone quickly needed a feature and added it without any deeper thought. Often with the idea that we would fix it later. Of course, later it was too late to fix it as it was already in use and couldn’t be changed. Another mistake we made was to never really document the reasons why many things look like they do and the reasoning behind it. Later we have found that people have not always grasped what are the fundamentals, at least as we saw them. The Erlang Rationale is an attempt to try and explain the reasoning behind Erlang and OTP.

Paolo – At the Erlang Factory London 2011, you will give the following talk: “A True Conversational Web”, can you provide us an insight on the topic?Robert – The classic web protocols are driven by the client, it is client which sends requests to servers which then reply to the client. While this works well in many cases there has been a steady move towards sites which have a much more interactive interface to the client. The client and servers hold a conversation with each other. While it is been possible to “fake” this with the old protocols websockets provide a much cleaner and intuitive way of doing this. My talk is about how well Erlang’s concurrency model matches websockets, and it also shows how much easier they can make implementing the current protocols.

Paolo – Who should follow your talk? What are the technical prerequisites needed to attend it?Robert – Anyone who is interested in web programming and seeing how Erlang can be used to program web applications. The technical prerequisites are very basic: some knowledge of the fundamentals of the web protocols and programming Erlang are helpful. Hopefully, I can explain most of what I go through.

Paolo – Can you suggest to our users some Erlang open-source projects which could be related to your talk?Robert – The obvious choices are the various web server libraries written in Erlang likeyaws,misultin, cowboy, etc …

Paolo – Lately you have been interested in websockets, do you think this technology will be widely used in the future? Is this the end of comet?Robert – I think it is definitely an interesting technology as it provides a clean way of doing things which require some form of server push. The current ways are in many respects impressively smart “hacks” to get around the limitations of client driven requests. Even if websockets become widely accepted it will be a long time before we see the end of comet.

Paolo – What should we erlangers expect from the future?Robert – More and better! 🙂 Seriously, the use of Erlang is definitely spreading to many new types of applications (look at the talks in this and previous Erlang Factories) which should lead to new insights how Erlang can be used.

Today I will publish Michael Williams’ answers. Michael is a co-inventor of Erlang (he wrote the Erlang Virtual Machine and implemented fault handling and dynamic code replacement primitives). Michael is also a manager at Ericsson.

Ask and answer

Paolo – Please Michael, introduce yourself to our readers.

Michael – I wrote my first program in 1968 in FORTRAN on an IBM 1130 computer at Cambridge. You had to wear a white lab coat to be allowed to go near the machine which filled a whole room. When I graduated from Cambridge, I moved to Sweden, because I got married in 1969 to a Swedish girl. I got a job at Ericsson (or L M Ericsson as it was called then) as a hardware designer for local telephone exchanges.

Paolo – Your educational background was focused on Mechanical Sciences, why and when did you start programming?

Michael – At that time Ericsson made exchanges based on switches controlled by relay logic. Exchanges filled whole buildings. We replaces the relays by simple logic circuits, DTL. At the same time Bell Labs in the USA were making the first computer controlled exchanges and Ericsson was following suit. It became clear to me that this was the future of telecom, so I enrolled in an Algol 60 programming course. Algol seemed so much better than FORTRAN I had previously used so I realized that the mainstream (FORTRAN, COBOL etc) weren’t necessarily best. Of course at that time, we used assembly languages for our computer based telecom equipment.

Paolo – The Erlang project started in the 80s. How much challenging was at that time designing a non C like syntax, non O-O, functional and single assignment language?

Michael – Don’t forget that in the early 80s “C” wasn’t widespread at all, Ericsson invented PLEX. I am going to say a bit about PLEX in my lecture, so I won’t expand on this at all. Even O-O got off the ground in the 80s although it had been around longer in Simula. At that time the Computer Science Lab in Ericsson was very much into Prolog. It was obvious that Prolog could solve the same problems as “C” in a fraction of the lines of code. Following the mainstream wasn’t an option, we simply wanted to make the best possible language.

Paolo – At the Erlang Factory London 2011, you will give the following talk: “The true story of why we invented Erlang and a few things you don’t want to tell your manager”. Can you briefly introduce the topic?

Michael – It’s about why we made Erlang the way it is. It is also about my experiences a manager in Ericsson and the challenges of introducing new software technology.

Paolo – Why should Erlang developers attend your talk?

Michael – It’s always a good idea to understand how things have developed, not just to accept things the way they are.

Paolo – You developed the first Erlang virtual machine and worked out the primitives for fault handling and dynamic code replacement. Which task was more difficult and why?

Michael – It wasn’t really difficult to implement things. Experimenting with ideas to find the best solutions for fault handling and code replacement was the hard part. The idea of fault handling stems for the idea that if you are going to be able to recover from software errors, you have to isolate the parts which does the recovery from the part where the fault occurs. Of course the part doing the recovery has to be as small as possible because it has to be correct.The ideas behind fault handling in Erlang come from relay logic, the “C” wire, which could reset relay equipment to a stable state.

Paolo – In your opinion, what are the most wonderful aspects of Erlang?

Paolo – According to many expert developers, Erlang’s syntax for records is error prone. Do you agree?

Michael – Absolutely, I agree.

Paolo – In 1990 you switched to management, how does your past experience as developer affect your current work?

Michael – As a manager, I have always been able to see beyond the current “mainstream” technology. A lot of managers are frightened of leaving the safe, C++, Java world.

Paolo –you are one of the main characters of “Erlang: the movie”, how does it feel to be a super star? 🙂

Michael – Hello Joe! Hello Robert! When we made the movie (I think it must have been in 1991), we really took it seriously. That it had a Monty Python flavour only became apparent later. By the way, I have at last stopped wearing a tie..

Paolo – Would you like to tell us something I didn’t ask you?

Michael – How new technology get introduced is a very interesting topic. Why did C++ take off, what caused people to adopt Java? Why has Erlang taken off after being so small for so many years. I wish I knew the answers!

Today you will read Simon Thompson’s interview. Simon is Professor of Logic and Computation in the Computing Laboratory of the University of Kent, moreover he is one of the authors of the project Wrangler. He also wrote with Francesco Cesarinithe book Erlang Programming.

Ask and answer

Paolo – Hi Simon, how would you like to introduce yourself to our readers?

Simon – Hi, I am Simon Thompson, and I have been at the University of Kent since the early 1980s. I teach a variety of subjects, but my favourite – and the area where most of my research is focussed – is functional programming. Recently I’ve been working on building tools to help programmers to be more productive and with my colleague Huiqing Li have built the Wrangler tool for refactoring functional programs; I talk more about that later on.

Paolo – You have been teaching computing at undergraduate and postgraduate levels for the past twenty five years. Do you think functional programming spread is growing?

Simon – Certainly: you can measure this in the number of jobs on offer, by the growing interest in different languages at the major open source conferences, and by the action around functional languages in the open source community. Specifically you can see this in the contributions to the Erlang system on github and in the number of open source Haskell packages contributed to Hackage.

Paolo – In your experience as teacher and developer, what is the most difficult thing to learn in Erlang world?

Simon – Experienced programmers coming to Erlang find the functional basis quite dis-orientating: how can I program without “proper” variables and control structures? It takes time to see that this can be done with tail recursion and “loop data”, and then a bit more time to internalise this so that it becomes second nature. Other concepts, such as “processes that share nothing” sell themselves more easily.

For beginning programmers the problem can be a different one: they can be unhappy that they can’t write “real” programs in whatever functional language. That’s partly the fault of the textbooks (mea culpa) but also due to the lack of support for realistic libraries, bindings etc. That has changed, and in both Haskell and Erlang it’s now straightforward to program more realistic systems.

Paolo – And what are the most common errors developers do when coding in Erlang?

Simon –Errors are so individual, it’s hard to single out particular ones. At a higher level, one of the more difficult lessons to learn in Erlang is to “let it fail” and not to program defensively, instead letting the context and the infrastructure deal with the crash.

Paolo – Based on your experience, how would you characterize the degree and quality of the collaboration between Universities and businesses?

Simon – Big question. First, as an educator, I really value student co-operating with industrial partners to offer students one year “sandwich” placements, where they work for a year during their studies. The majority of our students do this, and it’s a win-win-win. Employers get a chance to work with students and recruit them on graduation, students learn the practical aspects of computing which we simply can’t teach in a university classroom, and the department benefits from more focussed and more motivated students, who actually get improved results in final exams as a result of their placement.

As a researcher, I have benefited from working with a variety of companies, and particularly Erlang Solutions Ltd. We have together received two tranches of UK government funding for “Knowledge Transfer Partnerships”, one for using refactoring techniques in practice and the other for e-learning. in each case there’s been two-way traffic: ESL have given us a practical context for our ideas, “tensioning” what we do to make sure it’s useful, while we have been able to roll out academic ideas into practice. In the ProTest project, which is funded by the European Commission, a number of universities have benefitted from collaborating with Ericsson, Lambda Stream and Quviq as well as ESL, and this has given us invaluable feedback about what;s useful in the tools and techniques that we’re building, like Wrangler.

Paolo – At Erlang Factory in London, you will give a talk on DIY refactoring with Wrangler. Can you tell to our readers what is Wrangler?

Simon – Wrangler is a tool for refactoring Erlang programmers, written in Erlang and accessible within Emacs and ErlIDE as well as on the command line. Wrangler implements a whole collection of refactorings, and “bad smell” detection, and applies these refactorings across complete projects.

In particular it can be used to detect and eliminate code clones. We automate the generation of reports of clones, as well as the transformations themselves, but the selection and direction of these is very much under user control.

Paolo – Why should Erlang developers use Wrangler?

Simon – It can help you clean up your code, by getting rid of bad smells coming from clones or from problems in the module structure of the system. Those are the “occasional” refactorings, which you might do every once in a while, but others – like function extraction – are transformations that you might well want to do in your day-to-day programming practice: hence the reason that we have built Wrangler into the common IDEs. Finally, using the clone detection and other tools can help you to understand how some code works, if you’ve inherited responsibility for a test suite, for example.

Paolo –Can you suggest to our readers some resources online to learn more about Wrangler?

Simon – There is a guide to getting started and links to YouTube videos at the Wrangler home page. Please mail me if you have any feedback or comments on the system, the videos or anything else to do with Wrangler; we’d really like to have your feedback.

Paolo –You wrote also “Miranda: the Craft of Functional Programming”, and “Haskell: The Craft of Functional Programming”: why should an Erlang developer learn one of these two other languages?

Simon – Haskell is different from Erlang in quite a few ways: it’s lazy, doing evaluation on demand, it’s side-effect free, and most importantly it’s strongly typed: every expression and definition has a most general type. This means that when we’re writing a program in Haskell the first thing to do is to write its type: whether our program has that type is then checked by the compiler. This keeps you “honest” and avoids a whole class of errors, which in Erlang might be caught by dialyzer, but also might not.

Can I conclude with a plug for the third edition of the Haskell book, which is out in mid June: more details here.