Bio Mike Williams co-founded the Ericsson Computer Science Laboratory where, among other things, Erlang was created. Mike's developed the first Erlang virtual machine and worked out the primitives for fault handling and dynamic code replacement. Since the 1990s, Mike has been in charge of both large and small units within Ericsson which develop software.
The Erlang Factory is an event that focuses on Erlang - the computer language that was designed to support distributed, fault-tolerant, soft-realtime applications with requirements for high availability and high concurrency. The main part of the Factory is the conference - a two-day collection of focused subject tracks with an enormous opportunity to meet the best minds in Erlang and network with experts in all its uses and applications.
Well, I am Mike Williams as you just said, I’ve been a manager for Ericsson for about twenty years, before that I used to work with the Computer Science Laboratory. Nowadays I actually I am not a manager anymore because I am going to retire next year and I am busy winding down and got a staff position for the moment.
You could say that I was there when it started, we had a mission to try and improve the software productivity and I was asked how to go about it and after a large amount of experimentation we came across the idea that we need a better programming language and a better programming environment and together with Robert, Joe and and many others we succeeded in producing Erlang.
Before Erlang we at Ericsson programmed in a language called Plex and in fact at Ericsson we still do programing in a language called Plex which is a concurrent, low level programming language, from which a lot of our products are still made, we still make a lot of money from it. But Erlang was an effort to try and improve our productivity to make it even better.
It was used in lots of wireline equipment, we don’t do so much wireline equipment as we do nowadays, but it’s used in mobile switching centers and base station controllers, and a lot of other equipment.
I think our problem was to do exactly the same, to exploit the same features that Plex already had but to make a more modern language, do the same thing but not really - efficient, is the wrong word, but as far as the programmer is concerned - a more efficient way to program.
Oh, yes of course it can be done with other tools as well. I mean when you talk about programing everyone has their favorite programming language and their favorite way of doing things and Erlang is just one solution we use a lot of other solutions, in fact our current generation of mobile switching systems infrastructure is actually not based on Erlang it was based on other programing languages.
Indeed yes. The quick introduction is that if you have a good new technology which works that many good managers will take it, but unfortunately many managers are also bound up by the legacy that they already have, a lot of their software. For example if you have written a system that contains six millions lines of code say in C++ or Java or something like that, adding a little bit of Erlang on top of it is not going to help very much. But if you are starting something completely new, then it is easier to sell it and it is easier to get it accepted.
8. What are your tips for companies, should a company today actually like Ericsson did, just go out and create their own languages if they want to improve their work or should they go outside and use new technologies?
To some extent I think the era of creating new languages has passed. I mean Erlang is not the only functional language of its type we have Haskell, we have OCaml and we have other functional languages, I think that at present there has to be a very pressing need to do something like that. Now for the moment a lot of companies are using old fashioned technologies and their best bet is to jump on to more modern technology that already exist rather than inventing new.
A lot of C based languages but for example I am not exactly a fan of modeling myself but I know a lot of people like it, it’s a good way of improving programmer productivity and I prefer functional languages but then to a large extent that's a matter of personal choice and personal preference among programmers and companies.
UML modeling yes, definitely if you look at the way we have designed our base station equipment today we would not have been able to do that if we hadn’t used the tools for UML modeling. I am not saying that was the best way of doing it and that we couldn't have done that in Erlang as well but that is the way we chose to do it at the time.
For large scale design of control system software and not usually for digital signal processing but for the control system software large scale design you always have a problem when you have a team of a couple of hundreds programmers working on something you need a concerted effort to get them all pointing in the right direction, following specifications and doing everything right, and I think this is where a lot of people don’t really understand the assume that the same technology which is suitable for writing software for very small applications can also be used for very large applications, you need extra tools and extra ways of working both like modeling or alternatively just configuration handling systems have to be more sophisticated, that very large projects are significantly different than very small projects.
I think domain specific languages are very useful for certain applications, that for example we are looking heavily into domain specific languages for digital signal processing, a very tricky part of our application is analyzing the data which comes from the antenna or going to be sent to the antenna, to extract information for one user from a huge digital bit stream, and this is done by DSP programming to a large extent which is today very costly in terms of it costs a lot to produce the software. And domain specific languages can be very definitely be used in that area.
It can be today we use DSPC, but we need to make it more efficient and one way of doing that is by using domain specific languages and incidentally that is a complete area for which Erlang is not appropriate.
Yes. It’s too low level and the performance requirements mean that you have to program close to the hardware to get to the efficiency you need. On the other hand if you look at the actual volume of DSP software that needs to be produced in for example a base station, it’s significantly smaller than the control system software so if we used for example Erlang or code generation from UML, that is ok for control systems but not for what we base band processing. In other words the DSP is a heavy part of the software.
For the moment we are not actually using them we are investigating we are doing research in the area. And we are using a prototype together with the University of Gothenburg, with a system based on Haskell. But it doesn’t actually run Haskell you use Haskell to generate the code so today we are actually generating code from a domain specific language implemented in Haskell which produces DSPC.
No, Haskell is the compiler and a lot of the language is Haskell-like.
Low level programming and I think if you are writing long sequential applications then Erlang is appropriate when you have large parallel applications, multi core applications, multi process applications, network applications, things that communicate with each other, which are very communication heavy, then Erlang is an ideal solution. But you have to remember that one size does not fit all. Whereas I definitely think that Erlang has huge potential in some areas some other language and technology has better potential for other areas.
I think Haskell is an ideal language for certain writing for example compilers and that sort of thing. But it’s very difficult to make a general statement. I think today’s modern programmer can’t rely on just being an expert in one language they used to be once upon a time, I think they have to use a battery of tools which is acceptable for the problems they have to solve.
Again you are talking about personal prejudices and when I say that I personally don’t like object oriented programming that is definitely a personal statement which comes from me and should be no way interpreted as a general statement coming from Ericsson or anything like that.
20. So just talking about mister Mike Williams why don’t you like it? If you would write your own program after you retire and you start an open source project and it’s not object oriented? Why? Why would that be?
Because I find that functional programming approach fits my mind much better than the object oriented approach. And again it’s what I know it’s what we invented ourselves and not invented here is actually an important aspect to it. But I think things like Erlang for the applications we have is ideal because I think large scale object orientation I can’t get my mind round it. But I am sure there are other people that can do so.
I think you can still see traces of Prolog in the syntax, I think the fact that Prolog was dynamically typed has actually gone into Erlang as well as Erlang is a dynamically typed language but apart from that I don’t think possibly you can think that pattern matching and instantiation of variable has a certain similarity to Prolog logical variables but I think that maybe that’s a bit far fetched to say that, but it definitely has influenced our way of thinking.
I think not many people talk about Prolog today because I don’t know why which is a shame because again I think Prolog is a very good language for constraint programming and for solving logical problems, but I met the other day a couple of students from a Swedish university who were supposed to be the star students of the year and I asked them "Have you learnt what you do in logic program, did you learn any Prolog?" - "No, they said, we don’t." I think it’s a shame because I think it’s in every University education I think you should be familiar with as many paradigms as you possibly can be.
Not extensively but there are applications where logic programming is used that for example we have some applications for frequency planning for sales in mobile radio networks, and we are also looking at, we have designed a lot of our own DSPs for special purpose applications so we are also looking at using constraint logic for writing backend optimizing compilers but it’s very much a research project.
No, actually this is a constraint logic system, written by a professor from the Royal Technical Institute in Stockholm, Christian Schulte, we are looking at his stuff to see what we can do with it, that is to say what I am talking about is research not applications.
25. You mentioned Plex and Erlang both are very good at concurrency and expressing concurrency what kind of influences were there in the 80s and 70s for that? Did you look at the Transputer for instance?
Yes we did, it was one of the languages we evaluated for looking into what we did our investigation and what we can actually do was actually Occam. And actually I myself wrote a program for setting up telephone traffic in Occam. I think that must have been in about 1986, 1987 or something like that. Weird language Occam.
No, I think that Occam you never really know what’s happening because you write PAR and then you write other expressions afterwards, and you don’t really know in what order they will be evaluated or how they will communicate with each other. Since a long time ago I have forgotten a lot about it but I remember thinking that the programming was getting totally out of control.
Yes it does. It’s synchronous, yes.
I was involved in ADA that again was during the 1980s and at that time we were considering using ADA for programming telecommunication equipment. ADA at that time people thought that it might be the next large programming language, it didn’t turn out that way, which to some extent it’s a shame because there are a lot of very good things in ADA.
Yes, but it didn’t become large in the same way as C++ became a large language.
I haven't kept up with what happened to ADA today but if you go back to when we were looking at it the concurrency was implemented by synchronous rendezvous and the rendezvous turned out to be an inappropriate way to express a lot of telecommunication problems when you have two sides, for example a telephone call if we tale a very simplistic example has got two sides of two users which are doing things totally asynchronously from each other. And you need a two-way communication. We found that to do things in ADA we had to use lots of messager tasks and the whole programming model was very very messy.
CPUs all over the system. We make our own hardware from CPUs to special radio equipment, there's very little of a base station, which can be made from standard off the shelf hardware.
No, no. we have CPUs but we make our own CPUs which own ASICs we have to do that but that does not necessarily mean that our ASICs, we are making our own CPUs we're just using embedded CPUs, for example PowerPCs in a lot of our ASICs, a lot of our current generation does have actually Power QUICC computers.
If we go look at the base band, the DSP area that we are using Chips with 64 cores simply to be able to munge the data which comes in and do something about it. A lot of the data is heavily into use of multi core.
34. To finish up now that you are going to retire and you have some more time on your hands for a bit of programming what language would you use to write a bigger personal project? If you couldn’t use Erlang or Haskell?
My basic experience programming is that I consider that you can use Erlang or Haskell for the high level stuff or use C for the low level stuff and you really don’t require anything in between them and I think I know it would possibly sound strange but what I really enjoy doing is writing C so I would probably write a lot of pure basic C, it’s a good language for what it is good for.
I hope you look at Erlang as well.