Posted to tcl by ro at Mon Sep 21 20:36:26 GMT 2009view raw

  1. Seibel: Another difference these days is that you can no longer understand
  2. the whole system from top to bottom. So not only do you have lots of
  3. choices to make, they’re all about which black boxes you want to use
  4. without necessarily fully understanding how they work.
  5.  
  6. Armstrong: Yeah—if these big black boxes don’t work properly, and you
  7. have to modify them, I reckon it’s easier just to start from scratch and just
  8. write everything yourself. The thing that really hasn’t worked is software
  9. reuse. It’s appallingly bad.
  10.  
  11. Seibel: Yet you’re the architect not only of Erlang but of an application
  12. framework, the Open Telecom Platform. Is it reusable?
  13. Armstrong: To an extent it’s reusable. But the same problem will occur. If
  14. that framework exactly solves your problem—if some programmer who
  15. doesn’t know anything about the design criteria for OTP looks at it in a few
  16. years’ time and says, “Oh, that’s great; that’s exactly what I want to do,”
  17. then it’s fine and you get this measure of reusability. If it’s not, then you have
  18. a problem.
  19.  
  20. Fairly recently I’ve seen people say, “This is really kind of artificial, we’re
  21. twisting the code to fit into this OTP framework.” So I say, “Well, rewrite
  22. the OTP framework.” They don’t feel they can change the framework. But
  23. the framework’s just another program. It’s really rather easy. And I go into
  24. it and then it does what they want. They look at it and they say, “Yeah, well,
  25. that’s easy.” They accept that it’s easy. But they say, “Well, our project
  26. management doesn’t want us messing around with the framework.” Well,
  27. give it a different name then or something.
  28.  
  29. Seibel: But do you think it’s really feasible to really open up all those black
  30. boxes, look inside, see how they work, and decide how to tweak them to
  31. one’s own needs?
  32.  
  33. Armstrong: Over the years I’ve kind of made a generic mistake and the
  34. generic mistake is to not open the black box. To mentally think, this black
  35. box is so impenetrable and so difficult that I won’t open it. I’ve opened up
  36. one or two black boxes: I wanted to do a windowing system, a graphics
  37. system for Erlang, and I thought, “Well, let’s run this on X Windows.” What
  38. is X Windows? It’s a socket with a protocol on top of it. So you just open
  39. the socket and squirt these messages down it. Why do you need libraries?
  40. Erlang is message based. The whole idea is you send messages to things and
  41. they do things. Well, that’s the idea in X Windows—you’ve got a window,
  42. send it a message, it does something. If you do something in the window it
  43. sends you a message back. So that’s very much like Erlang. The way of
  44. programming X Windows, however, is through callback libraries—this
  45. happens and call this. That’s not the Erlang way of thinking. The Erlang way
  46. of thinking is, send a message to something and do something. So, hang on,
  47. let’s get rid of all these libraries in between—let’s talk directly to the
  48. socket.
  49.  
  50. And guess what? It’s really easy. The X protocol’s got, I don’t know, 100
  51. messages, 80 messages or something. Turns out you only need about 20 of
  52. them to do anything useful. And these 20 messages you just map onto
  53. Erlang terms and do a little bit of magic and then you can start sending
  54. messages to windows directly and they do things. And it’s efficient as well.
  55. It’s not very pretty because I haven’t put much effort into graphics and
  56. artistic criteria—there’s a lot of work there to make it look beautiful. But
  57. it’s not actually difficult.
  58.  
  59. Another one is this typesetting system I did where the abstraction boundary
  60. I opened up is Postscript. As you get to that boundary you think, “I don’t
  61. want to go through the boundary,” because what’s underneath is—you
  62. imagine—enormously complicated. But again, it turns out to be very easy.
  63. It’s a programming language. It’s a good programming language. The
  64. abstraction boundary is easy to go through and once you’ve gone through,
  65. there’s a lot of benefit.
  66.  
  67. For my Erlang book, my publisher said, “We’ve got tools to make diagrams.”
  68. But the thing I don’t like about diagramming tools is it’s really difficult to get
  69. an arrow to meet exactly. And your hand hurts. I thought, “The amount of
  70. time to write a program that spits out Postscript and then say, ‘I want a
  71. circle there and the arrow goes exactly there,’ and get the program right,
  72. isn’t long.” It takes a few hours. Doing diagrams with programs takes about
  73. the same time as doing them in a WYSIWYG thing. Only there are two
  74. benefits. Your hand doesn’t hurt at the end and even when you blow the
  75. thing up to a magnification of 10,000, the arrow points exactly right.
  76. I can’t say beginner programmers should open up all these abstractions. But
  77. what I am saying is you should certainly consider the possibility of opening
  78. them. Not completely reject the idea. It’s worthwhile seeing if the direct
  79. route is quicker than the packaged route. In general I think if you buy
  80. software, or if you use other people’s software, you have to reckon with an
  81. extremely long time to tailor it—it doesn’t do exactly what you want, it
  82. does something subtly different. And that difference can take a very long
  83. time to solve.
  84.