1. What keeps you interested nowadays?
Joe Armstrong: I think it's the same thing it's always kept me interested actually, just because I've been thinking for many years about how you build systems, how you make complicated things from simple things and how you glue them together. The entire computer industry has manifestly failed in this, so it's always been a problem that's interesting. It's interesting: each new computer you buy it takes 10 seconds longer to boot than the one you bought a year ago. We put more and more software on them and they work worse. I talked to John Hughes and I said "There is this problem with computers, they get slower and slower with the time. How do we get faster and faster?" and he said "Yes, I know.
Somebody said the trouble if you put software on your computers you break them basically because they are getting slower. When you put one thing it stops the other stuff from working and that shouldn't really happen, because if you write a program and I write a program, then your program shouldn't bugger up my program, but unfortunately it does. We've learnt how to write programs, it's taken 30-40 years. We haven't learnt how to connect them together and put them in boxes and ship them to people. We've learnt how to control complexity on a sort of micro-level, but we haven't learnt how to control complexity on a macroscopic level.
That's always interested me. I'd like to stop the clock and go back to about 1980s. I was reading Smalltalk: Bits of History, Words of Advice and somebody describes the point when Smalltalk first worked. And they said they worked about 3 weeks with the image and they couldn't dump it because they hadn't written the code that could dump the image and modify the image. Then, they dumped it and then they said "It works!" I'd love to step the clock back and go and look at exactly what they had then, because as you add complexity after that, it gets to the point you can't understand it any more so I'd like to stop the clock at these critical points and freeze everything, so we can understand what's going on after that.
Dave Thomas: I think actually that's one of the unfortunate things of software archeology: you can't see the gem of the idea, the initial set of concepts. I certainly agree with you that this whole problem of complexity is out of control and that's certainly demonstrated by the challenges we have with today's technology. I really feel for people that are having to use this. How do normal people do this when most of the really smart people barely succeed with all these new things coming out all the time? What drives me is a similar interest, but it's how is it that a small group of people working on an application in a problem that's of interest can actually build that, get it done, test it and make it work.
That's something I've been interested in all my life. Basically how can you have something that's powerful enough, yet small enough that people can grasp that a small number of developers build, because we know that's how interesting things get built by a small number of developers. Is it somewhere that you can stop there and maybe connect it up with some other bits? Because it's clear that the fun ends and the problems begin when you start adding a lot of humans to the system or trying to bring in the assets from other humans into a system.
Joe Armstrong: What happens then? The small group do it and it works and then they get fed up because they don't want to go into this maintenance phase and they don't want to extend it so they slowly leave the project. Something that was understandable when they left it becomes something that is completely unmaintainable and incomprehensible 10-15 years later. At some point in that development something goes wrong. What is it that goes wrong and when? How can you stop it?
Dave Thomas: I think it's difficult, but I think one of the challenges is building software that's reasonably easy to maintain. One of the tests of really good technology or really good design is "Can you actually maintain and change this design?" Table driven system for example, very old systems, sustain this test because in the end you can just keep changing this table. It's obviously very simple and not applicable to everything, but the fact that you can have this thing last for so long and pass it from one person to another, that's really something that stands this test in time.
I think one of the issues is clearly if there is a lot of code, it just gets worse. So k-locks kill and the more you have, the worse it gets. One of the problems is that whenever you have a really elegant solution done in an expressive creative way which may use a new technology or a new method, that's really understood and it's a culture that's built up. What happens is that there are industry trends which say "Well, that may be a very good culture and you've done a really good thing, but in order to be safe, we have to move to whatever the standard technology is." That move tends to inject a lot of mediocrity into the thing, basically a lot of process.
2. Communicating Specification and design
Joe Armstrong: I wonder if one point isn't that we sort of assumed that you can write down design decisions on a sheet of paper and the designer doesn't have to meet the implementer or the maintainer. I work in industry and a lot of the time basically you read documents which you don't understand. I read design documents like that, I don't know if I'm stupid or something like that but I don't understand these documents and I have to go and find the person who wrote it and get them to explain it to me.
When they explain it to me I can understand. It's a fundamental difference between a document and a person because the person is interactive and if you don't understand something, you can ask, you can stop. You are reading this document, say "I don't understand this", you ask a question and the person explains. That's an answer just for you and nobody else and that's not captured in paper or in the specification, there is no way. If we believe the specifications replace human beings and replace communication, you are out. Most programmers don't write good documentation anyway - an API isn't documentation.
Dave Thomas: Or any business analysts or anyone else for that matter.
Joe Armstrong: Quite often with code you can see how it is written and what it is, but you don't know why. You have to ask "Why did you do it this way?" and it's not captured in the design process at all.
Dave Thomas: Design capture has been a challenge, it's eluded almost everyone. Certainly, in the Agile Manifesto every case and notion of the customer or the user is being there, but they are not always there. It's often the case that people have this sort of knowing "I know what this person is doing, because we work together". Then, when they work with someone else, that implicit communication isn't there. It's certainly complicated thing which we really don't understand. But one of the notions that you can sit some place and write it on a slate and pass this slate to someone and say "Just do this!" it's a fiction in someone's imagination.
3. Overestimating tools and process and underestimating brain and experience
Joe Armstrong: I think we overestimate the value of tools and processes and underestimate the value of the brain. If it's like a spectrum, you've got some tool Emacs and a few other things down there and you got your brain over there, and the brain is so amazing because it takes in all this information, then you go to sleep and you wake up the next day having solved the problem. And you haven't followed a design process. It's just so superior to any tools we have.
Dave Thomas: We just don't want to accept that software, like many things is actually a craft, in that the people are very important. One of the major fallacies of the whole McKenzie school and the process is that if we have a process and we get the right way of doing this, that we just need to hire so many red ones and so many blue ones. And they can do this, when, in fact, anything that's interesting and new and it's going to last, it's typically made by some actually fairly special people who somehow got together and managed to communicate with each other about something that was complicated and then built it.
Joe Armstrong: Talk to somebody over a compiler writer or something, it's like Stradivarius, it's making a violin or something. You practice for years and you handcraft these things. It shouldn't be viewed as a sort of industrial process where you can specify a new amount and send it over to India to be implemented. It's not going to work!
Dave Thomas: It's a complete nonsense. In engineering we accept there are components and component knowledge, but the rhetoric today is "We'll have everyone in the team and they all can do this." If I've been building DSP drivers for 20 years and I've been doing graphics programs for 20 years I'm not going to be competitive with some new person that's just come in and done this, because it's a lot of knowledge and a lot of specialty. The notion that we can just plug someone new in here and they'll just sit with someone else is completely inconsistent with the fact that it doesn't value experience. You're good because you've done it wrong all the other ways before.
Joe Armstrong: The nice thing about expertise is they talk relaxed persons asking them how they do it. They go "I don't know really. I just knew it was right." They use intuition a lot. Beginners don't have intuition. Beginners like test driven development and things like that because it's a substitute for intuition. They don't know it's right, they have to be shown it's right by the computer. Experienced designers know the design is right, they don't need to test it. If the test cases say it's wrong, they say "I haven't done it wrong, because I know it should be that". If you ask them why they know, they don't know. That's a sign of the experience, it's gone into their subconscious.
Dave Thomas: We certainly keep resorting to processes and simplifications, such as test driven development or formal specification or whatever it is, but the reality is that it remains a craft, it means people can communicate with each other. Often the tools they select and the way they do things is very different, even the basic notions of collocation, which is the rage that says "If you are not collocated together you can't possibly do anything significant". That's a big thing in the Agile community.
My point is I'd rather be in the same mental space with someone halfway around the world than collocated with someone else I can't communicate with. The open source projects and many successful things have been built by teams around the world. My most interesting intellectual exchange has been with people that I've never met or that I met in the world thousands of miles away. I just think there is a lot of rhetoric. Again, it's because people want something simple because they can basically tell everyone "Look, it's easy! You just have to do these 5 things and you will be able to do development".
4. Continuous rewriting for new technology and trends
Joe Armstrong: The whole software industry frequently gets into an enormous mess and then something new comes along and we got to reinvent it all. We will use object orientation, it will make the code reusable, so yes, you got to rewrite it again. But once you've rewritten it again, you've got in that initial investment pay off because you can reuse stuff and then everyone buys into that, 15 years later it's so great because we've messed just like the last lot was. Then somebody comes along and says "OK, forget that object oriented stuff. Do it in functional programming" and they will do it in functional programming and we'll write some mess in 15 years time and then somebody got to do category theory or something like that. That's a process which has happened many times before.
Dave Thomas: I think one of the issues is that basically people choose new technologies when they're desperate. The people I meet who are choosing to go to new technology, be it Erlang, functional programming, OO, Agile. Some of them are actually enlightened and making an informed choice, but many are at a wall at some point. The management accepts some story "If you let us do it this way, we'll get it done and it's not possible any other way."
They basically make the mistake that they sell the miracles which management looks for and then they don't get the time to gain the experience to actually polish and finish it. I think it's because they actually reinforce the miracle expectation without really having the experience of "How long will really take us with this new way, because we'll have to learn first and that means we'll have to fail a few times and learn from it?" They propagate it by never providing enough time for even the new way to actually become a new practice.
5. Recurring management mistakes and optimism of a software development team
Joe Armstrong: What amazes me are the project managers who have never read books or something like that, are adding more manpower to a late project which makes it later. They say "Haven't you read this classic software readings. It's always been true." And they still do it. Haven't we learnt anything? It's crazy!
Dave Thomas: First of all, when you present them and they haven't read it, it comes back to the optimism of the software development team, because often they get put in that situation. It's sort of "Come on boys! Can you not do it?" You get that kind of team pressure "Surely we can! We really need this one!" and they get sucked in and they talk to each other and they come back and they have some beers and they say "We think we can do it."
They validate the "We can have a baby in 3 months" because they don't really live by the software physics that they know. I think one of the challenges is for people to be honest and say "We don't think we could possibly do this". Agile gives you promises, predictability and quality. It says nothing about productivity. Inevitably, you get in there and people are talking about "How much more productive we're going to be?" Where did that come in the equation?
6. Consumers' low expectations regarding software
Joe Armstrong: It's funny, because if you look at say academic software, where academics are looking for evidence and proof and you look at the commercial software there doesn't seem to be any evidence and proof. There are people coming out with software things all the time and they go to the trade phase and they are advertising something and they say "This is great for doing this!" OK, where is the proof? Where is the scientific evidence that this stuff works? They haven't got any. Worse, you even got to buy the thing to even find out what it is. You just get the advertising hype and it amazes me that so many people buy stuff just from the basis of no scientific evidence.
Dave Thomas: My claim is that you have crappy software because people are willing to buy it. Again, it's a consumer problem, they want to have the latest thing and they don't really care whether it works. They want to be with it so they want to be using this new thing because that's something seen to be doing, something you do. They're prepared to ride a bicycle with one wheel, just to be seen to be on it, it seems. I think the consumer is going to actually say "Look, I expect this computer to work. I don't really want my TV to have to boot, I don't want to hear from someone that I have to reboot my TV over the cable network. 'Could you pull the cable out and pin 5, just giggle it up and down a bit, it will be rebooted.' I don't want to hear 'reboot' again!"
Joe Armstrong: Why don't consumers complain when their computers take longer and longer to boot each year. It's very strange. I've never understood this: you expect the software in an aircraft to work; you expect the software in a pacemaker to work or in a banking machine to work, but you don't expect the software on your desktop to work. When it crashes or something, you go "I've got to reboot it" and you just shrug your shoulders. It's absurd.
Dave Thomas: I think there is an increasing number of people who aren't willing to do that and one of the things that people have is they are voting with their feet with regard to devices that are phones and computers and personal devices. They are looking for simplicity in terms of operating these devices. I do think it's something that's starting this out. At some point, people will not tolerate these things.
Joe Armstrong: My wife, she's got a macbook and she stared in amazement at it because the mouse wasn't following her finger on the keypad. "The mouse isn't moving!" she said. "What do I do? This has never happened before!" and I said "You can press the power button and reboot your operating system." She looked very surprised and she wouldn't have been at all surprised if it had been another well known manufacturer of computers. Perhaps they are all getting slightly better.
Dave Thomas: I think there is some notion. Until consumers demand that and until people are responsible not to say "Just because it's been announced, it doesn't mean that works". Part of the problem is there isn't any independent testing body either in the sense that we have many of the analysts and so on are bought and paid for by the vendors. So, if you want to be in the magic quadrant, you just have to cough up enough money. Or, if you are among the hot generation of technology or people then you can just announce something it's really cool, even though it's done before better and maybe even commercially available. But you will get enough twitter traffic and enough other things because there is no knowledge of that in another area, so it just becomes hot, until people are trying it out.
Smart consumers basically say "I'd like to use this second or third release." I want to get and iPad, but I don't want the first one. I think that's going to be common with NOSQL databases or new languages or whatever it is. Smart consumers are going to watch and say "OK, it seems pretty good for that, maybe not too good for that". It would be great if people could actually provide some demonstrations "Here is my new idea and here is a way that you could validate that it makes sense for you" or "Here, I've run a benchmark that you all know, and here is the same program written in this." But they often present a new program, which demonstrates how their language works very well for a problem which they've invented and solved which is unconvincing for me.
Joe Armstrong: "Why is your language so good? Have you written any big applications in your language?" - "We've implemented the compiler for the language itself for our new language, so that's a pretty big program." "But any other big problems?" - "No, not yet actually." Have you heard that?
Dave Thomas: Never. I am sympathetic to people that are bringing, implementing things as it is difficult, but there is that obligation to try and provide some sort of convincing demonstration. Or you have the initial customer say "Here is what we've done with it and here is the good and the bad." We are still in a world that values The New New Thing and The New New Thing is something that consumerism drives and people want that New New Thing and I believe the software is the biggest victim of that, because it causes things to be pulled prematurely before they're done, polished and tested.
I think we need a lot more than software fixed to change that, it's really a behavioral pan. Perhaps the green revolution where people don't need things. They want to be stable and sustainable, so I want a sustainable PC that I never after recycle or replace. It would be unacceptable for you to replace your PC except every 5 or 10 years. Maybe that would change things a lot and people will only upgrade their software - "I can't delete this software, I have to keep using it." But we need some pretty radical change to do that.
Dave Thomas: I think there are a couple of things. One is an impressive feed of doing something, implementing it very cleanly into the technologies impresses technologists in general, it should. The thing that really makes a technology widespread or pervasive is often commercial conditions. We basically saw that you can have a great technology and there have been many and will continue to be many where the commercial conditions were said that just wasn't something that was acceptable. Many languages were all but wiped out when Java and CLR came because it was difficult to implement those languages on top of that. If you look at the great work today of Martin Odersky and Rich Hickey with regard to Scala and Clojure, this is a really great engineering Kresten doing the work on Erjang, to get those languages to work on top of something like the JVM is a real engineering challenge.
They are still not out in the corporate world. I was part of the whole messaging, part of the big messaging with Java.- "You don't need anything else but Java. It's bad, you can't get the coffee cup if it's not all in Java." The original visual aid for Java was actually implemented in Smalltalk, but that was changed to be implemented in Java because in the end it meant that IBM would not get the coffee cup. You get this commercial event that happens and that will cause a wave. It may be smaller, it may be a commercial invented industry; one of these was Erlang. There are some areas which are really sweet spots that people would realize in terms of scalability, robustness and concurrency and that's creating fortunately (which is great) a great commercial opportunity for the spread of Erlang because there is a real need in a particular area in the commercial marketplace.
Joe Armstrong: I've heard several people say that for a programming language to succeed, somebody must make money out of it and somebody must be prepared to invest money in it and their own money in it, not somebody else's money. In fact, the areas where the Erlang has been most successful and that have driven a lot of publicity is perhaps not the sort of the sort of Ericsson thing which are corporately financed things, but it's the small companies where people put their own money in and build something and then go and smash the opposition.
Some financial places have grown to 200 people now and just got venture capital; the original financing was only the guys who started the company and they put their own money and they put their jobs on the line, they go and do this stuff. And then, they do very well and they outcompete the conventional people who are doing Java and so on in the financial industry. In that niche market you grow like hack.
The traditional actors don't pay any attention to start with, because something that's taking 1/10 of a percent of their income from them isn't a threat. But the growth rate in something like this company is 15% per year or something. It grows to be 200 people in 3 or 4 years or something like that. If it carries over that growth rate, it gets to be a 1,000 people in 4 or 5 years time and it begins to hurt, it begins to take 25% of the revenues from the big people, at some point they wake up and go "Oh, my goodness! What's happening?" If you repeat that all over the place, with lots of things happening because people are making money out of it, suddenly it explodes everywhere.
Dave Thomas: Then, people believe that anyone can do it, all you have to do is this right programming language.
Joe Armstrong: And then, at that stage they are too late to capitalize it.
Dave Thomas: That's right. And they realize it in the end. Typically it takes the appropriate engineering team to do that.
Joe Armstrong: One factor is somebody has to make money out of it. Another factor, I think, is there has to be an enthusiastic band of zealots who go and preach and so on. Then, you shouldn't underestimate the timing and luck. I've seen stuff that was absolutely brilliant but before its time and it failed. I reckon if it had gone 2 years later, it would have worked. Luck plays a great deal in it. Erlang and Haskell is on the rise, but is it due to the fact that they are good or to a disillusionment with Java and things like that? People are becoming disillusioned with old technologies. Is it that the new technologies are good or is it the disillusionment with the old technology? You don't know. The timing is very important.
Dave Thomas: It's certainly not something that has any predictability. Both the increment success and the sudden failure or downturn in the use of Smalltalk I would attribute as much to luck and timing. That was great technology and I love it, it's still one of my favorites, it is close to my heart, but commercial events create the opportunity, there is a demand in a certain market, you can do it and the big factories there are some companies that are successful and said "Oh, by the way - we did this in Smalltalk".
But they could have done it in Lisp, they probably could have done it in C in many cases, but because they did it in something different, they were going to attribute it "That must be the way that makes you successful." In the end it was a team of people that made you successful and not the technology by itself. It was that people and that combination with that technology and the way they built software that made this successful. You can't really separate those things out.
Joe Armstrong: I saw Dan Ingalls had a Smalltalk 72 to show to QCon and he made a pop-up menu that didn't only pop up, but when you clicked on it, it rotated and span around the screen and sort of vanished into the corner. That was Smalltalk 72 and I thought "Hey, my menu system can't do that today!" It was a user interface that was more advanced than what we have today. It hasn't anything that made it to Windows.
Dave Thomas: Similarly, you look at collaboration and if you are going to get the 1968 demo video Doug Engelbart, there are things in that collaboration environment that no collaboration system can do now in terms of to be able to add comment to another people's conversations and so on with this simple concept purple numbers and so on that Doug came up with. But it was not commercial, it was a commercial system under Deck 10 and as the Deck 10 went away. The closest thing for a bit was Lotus Notes so on and collaboration systems really didn't go anywhere. Now there is a new one coming in but you still can't do what you could do in Engelbart's NLS. It's kind of a random chance and bad luck and good luck and crazy opportunities for these technologies.
Joe Armstrong: I wonder if we haven't got over the peak of bad stuff. If you look back to days of Borland's Turbo graphics where you could just write a program in Pascal or something and you could say "Create a canvas, create a pen, draw a line that's green" and anybody could do this. In order to do anything that's GUI or graphics you need some tool and you have to click around in this nightmarish thing and it produces some software. Instead of drawing the conclusion that graphics program or GUI construction is being so difficult that can't do it by yourself and you need a program to do it, you don't draw that conclusion.
You say "It's a wonderful new tool" and you get to a point where virtually nobody can build a GUI without being a specialist or something like that and then you say "Couldn't kids do this?" and GUI says we'll reinvent basic, so that kids can program again. It's going to go back to the early '70s or something like that. I think the complexity has got so great and there are so many things to make programming very difficult. It's strange. But in other areas, programming is so much easier. The devil of complexity is getting in all over the place.
Dave Thomas: I think there is complexity and too many people and the belief that anyone can do it. Many of these tools are wonderful in the hand of a craftsman but the reality they are not that many craftsmen. The kind of education that many people have doesn't give them the ability. They learn about one family of tools and they don't get the general principles. There is a danger of just losing people.
We talked recently about functional programming to people who have never heard of functional programming and they find it quite terrifying, versus people who've got a good wide spectrum education, a good education that go "Oh, yes, functional programming. Yes, that would be good, I'd like to do more of that. I quite enjoyed that at a point in time. But if they've just sort of learnt the objects UML kind of thing you find it quite terrifying and justifiably so because it's thinking differently about problems is not something that they are accustomed to.
8. Great shortage of the experienced craftsmen and too much importance given to certification
Joe Armstrong: I think that if it is a craft, the way you learn a craft is by working with a craftman and then you will get experience and there is a great shortage of the craftsmen who've been doing it for 20 year who the other people can join in the industry and work alongside for 10 years learning the craft. You can't learn to program in 5 years. It takes you 10 years or so to get started.
Dave Thomas: I think they do really have to study with a craftsman, but particularly in North America we've often been giving people certificates because we decide it's more important to have a certificate than have to be competent. Competency isn't a requirement. You can take a 2 or a 3 day course and get a certificate on X, Y or Z, which says nothing about your competence or capability level. I have to say there is a lot more concern about craftsmanship but it's still in the very early stages because we really have need of talking about something where you have to study with a master craftsman or whatever it is.
When you work on so many projects and have so many things under your belt and say "OK, I've completed some designs and built so many things and tested them" so that you've earned it and that would be I would say 5 years. Most people know if you get a new electrical engineer, that the electrical engineer is completely useless for at least 3 years in your organization. You would never let them near any serious design, but you would have them work with the person doing a very important design, where they would be doing bits of it and getting the feedback, but in software we say "You can program. Just go!"
Joe Armstrong: There are all these books to learn Java in 21 days or something. It's more like you learn Java in 21 years, to be more appropriate. You can't learn anything in 21 days.
Dave Thomas: I guess my problem is if they were doing basic I would be more sympathetic to that, but Java is not simple. I think that's kind of dangerous and the problem is that they create things that are very complicated easily because they really don't understand - the notions of interfaces or any of the principles. But again, that comes back to the companies who basically are looking for how to get the cheapest developer. Many companies are globally now hiring their development stuff through a recruiting agency who can basically get them for the cheapest.
"I need 5 green ones and 6 blue ones." - "There are some blue ones and some of the green ones got painted green last week, they sent them on a Java course or they could be green and blue ones went on a C# course so they could be blue, they got a certificate from it." That's not professionalism, it's an insult to trades and qualified technicians all of whom study and work hard and improve their practices throughout, but I believe that's what the industry is driven the notion that you can just buy resources as programmers.
Some large companies (to remain unnamed) design it so they can outsource all the administration positions and that means they only hire people that the only thing to know how to do to be an assistant contractor is to have operated a certain calendar program and a certain email system. The only 2 things your assistant can do are those 2 things. But that's a job description. "You need an assistant? We can get you any of them. We got 500 purple ones over there and you can just pick one and bring him in." I believe it doesn't work, but somehow large corporations and their current business rather don't seem to get it across. In the end, people who think are important, people who solve problems are important and teams that can work together are important and small teams get things done.
10. Management that don't make a difference between good and bad software
Joe Armstrong: I think the trouble is a lot of management decisions are taken by people who don't understand software at all, so they can't distinguish between good and bad software because they can't understand it. One thing kind of amuses me. Look at open source projects; they vary from the best quality software I've ever seen that are drop-dead beautiful code and you see code that is so bad that it's appallingly bad.
The problem is it's written and it hasn't yet learnt that it's advantageous to format their code so that you can read it. You wonder over the pages and there are random spaces in it and you can't even read the stuff. Probably commercial software before it was all open source was actually pretty much the same. Probably the appalling depends of the very good stuff and it's just delivered as a black box and you can't tell.
Dave Thomas: I don't think there is that much difference between commercial source and open source in the end, because it just reflects the humans that are building it.
Joe Armstrong: But now you can see it.
Dave Thomas: In many companies, in the best companies, one of the reasons we didn't open source our software is because we were embarrassed by it. We can't put that out because although it was working, there are always some parts of any large system which you aren't exactly proud to show anyone. You know you really should document this better or you should restructure it but in practice, there are time and reality constraints. You all have some nasty narly thing that is very scary that you don't really want to show anyone.
Joe Armstrong: That actually sounds a more plausible reason than what they usually give - "It's got our intellectual property in it so we can't show it to anybody."
Dave Thomas: That's an excuse you can use. Good developers are pretty proud, I know many who would love to give the source out and things and they just go "This is so embarrassing. To do this you need all this other stuff which you shouldn't have to know at all, but it's this tangled web." I agree. I think there is a real danger because we don't spend enough time explaining software and software physics to people outside the discipline. It's funny. If you tell to learn it and the business analysts actually learn it, they can learn pretty quickly that an API is expensive. They write out a story card and they say "I want this particular story" and someone says "We need 2 APIs", as soon as they hear that, if they know something about APIs, they go "Oh, damn! Those APIs are expensive!"
So, they actually go back and try to see if they can find another story of higher value, a good enough value so they don't have to have APIs written, but very simple things we hide so much. It's so secretive and we don't provide a vocabulary and an explanation and we don't accept the rules of software physics that context switching has a cost. Then there are just basic notions that people have that aren't so shared. The design rules, which again are in the mind of experienced experts. You basically describe the system and they say "That won't possibly work for the following reasons", but that's something you only get by working with masters. In the end, we both have a passion for wanting to see systems built with separate components and allowing a small number of talented people to do that.
One of the other changes which we certainly did, reflect in the fact that we can somehow communicate to those outside our craft, what it is we do and how we think about things and how good things get built and how good people get trained and brought up that will continue to be complaining about the problems, in some sense, with the challenge of being part of the solution as well. I know when I talk to many business executives, they sort of spin the bottle and it stops and it goes "Joe, you're the CIO. IT reports to you. Congratulations!" and everyone says "We should take the poor bastard for a beer".
Many people who have this are really well-intentioned but they really don't understand what is they've got and they've got vendors coming in, they've got worrying IT factions that "We should be doing this in Erlang" or "We should be programming in Ruby" or "No, it should be on the CLR". They really don't know. I think it's very important that we find ways to explain these people. When I always coach these people to get outside people who come in to actually let the people who are arguing pick some experts that they would respect and have that brokered from outside.
Somehow you have to find ways to help people to understand, break the ties, not expect them to make decisions and not vilify them for the fact that they don't make the right decision or whatever it is. Put yourself in a similar situation where you'll be sitting there listening to a group of music contestants or whatever domain you are not the expert in and being told "Judge the best of these". If you are a software person, of course, you say "I just like this one, so you just do it." Hopefully we wouldn't; we go "I really need someone who understands more about music, more about how this should be performed with this particular instrument, to help me do this. I can't possibly be the judge of this without someone who has the expertise and experience."
Joe Armstrong: There is the danger of programmers sticking too much inside that language. If I think Erlang is good (I do think Erlang is good), if I were to convince lots of people that Erlang was good, I would write an awful lot of applications in it. Perhaps that's not so good, because it's not good where you have one group of programmers and they can only think in Erlang terms and only write in Erlang terms and another group who can only do Smalltalk and another group who can only do Java and they can't talk to each other.
This would be like human languages. We've got people in England and they're all talking English and over there, we've got people in France and they're all talking French to each other and we've got people in Germany talking German to each other. They have awesome things when they communicate a lot. You open up lots of new possibilities. It's really great we can talk to the French and their cheese can come over and their wine and things like that. I think the problem is if you concentrate too much here in the box looking at your language, all the time you spend looking at your language is time you're not spending looking at the space between the languages.
You are staring at your Erlang stuff here, you are staring at Smalltalk same and then, when we want to do something together, we find we can't because we've forgotten the space in between and we don't know how to talk to each other. I'm very pleased that you come to an Erlang conference, we need people to bridge these zones and talk these different languages. However we like our language, we're not going to conquer the world and not going to get everybody use Erlang or Smalltalk or Java or anything for that matter.
Dave Thomas: I think of the interesting universal things is that whenever language designers, implementers meet, almost always the good ones are trying to figure out "What can I get out of my language?" We had this discussion "Do we really need all this stuff we've got in Erlang?" because this languages grow and these systems grow. Inevitably, we're back to Joe's earlier comment when it was just sort of starting when that germ was there.
Joe Armstrong: We really need floating point numbers.
Dave Thomas: Like many things, the essence of design is knowing what to leave out. One of the problems with software is it's so easy to put more stuff in. It's so difficult to take things out. It would be nice to have a world in which smaller languages can collaborate and I think that's the future that we really see. The important thing is to have languages which have less baggage to collaborate. I've been trying to figure out how to make my language so it becomes both a desert topping and a floor wax to use this very nice line of quote.
Joe Armstrong: Nicholas Viet said whenever you put something into a language, you must take something out. So, often when people propose extensions to Erlang, I agree with them. I say "That's really excellent! We should put that in the language. What are we going to take out?" They say "What do you mean?" - "Well, if we just stuck more stuff in, we lose our first goal, which is simplicity. If we put something in, we have to take something out. I don't see taking things out."
Dave Thomas: I think that's really the test of any good design - "What are we going to leave out?" It's a classic problem of products that don't ship, because the product is going to do everything. The reality is that something has to be left out. The key is my decision, the ability to leave things out is really the key to a great design.
Joe Armstrong: Those are more difficult decisions to make.
Dave Thomas: Absolutely - the most difficult. It was great to talk to you here, Joe.