Programming 版 (精华区)

发信人: armstrong (小小), 信区: Programming
标  题: An Interview with A. Stepanov
发信站: 哈工大紫丁香 (2001年11月28日15:22:27 星期三), 站内信件

From http://www.stlport.org/resources/StepanovUSA.html

  An Interview with A. Stepanov
  by Graziano Lo Russo
Edizioni Infomedia srl
  Question:
May you introduce yourself?
Answer:
I was born in Moscow, USSR, on November 16, 1950, and studied Mathematics at
 the Moscow State University. But I never became a mathematician. I could no
t really get excited about Tamagawa numbers, Coxeter groups and other things
 that I was supposed to specialize in. Hardy's hope that his mathematics is 
never going to be applied is not for me. I need to do something a little bit
 more real. I was fortunate, however, to see some great mathematicians at wo
rk and became totally immune to a pseudo-mathematical rigor that unfortunate
ly is so common in Computer Science. So becoming a programmer was a really g
ood thing for me. In 1972 I became a member of a team developing a new minic
omputer to be used to control large hydroelectric power stations. I particip
ated in all parts of the design, from architecture and hardware testing to O
S (my first published paper was on real-time operating systems) and programm
ing tools. I learned first hand about both software reliability - power stat
ions are hard to reboot - and efficiency - the water is coming down in real 
time.
At that time I also discovered books of two great computer scientists from w
hose work I learned the scientific foundation of my trade: Donald Knuth and 
Edsger Dijkstra. Knuth taught me the answers. Dijkstra taught me the questio
ns. Time and time again I come back to their works for new insights. My next
 important career step was spending 5 years at the Computer Science Branch o
f General Electric Research Center in Schenectady, NY. I worked on a very hi
gh level language called Tecton and read a lot: from a plethora of papers on
 programming language design to Logical Summa of William of Occam - Aristotl
e and medieval logicians knew a lot about different kinds of logical structu
res that appear in the natural languages and their formal properties. At tha
t time I started a fruitful research collaboration with Dave Musser which is
 still going on. In 1984 I became an assistant professor at Polytechnic Univ
ersity in Brooklyn, NY. Teaching Computer Science did me a lot of good - I m
anaged to teach all kinds of graduate courses, learning a lot of new materia
l in the process. I also developed a large library of algorithms and data st
ructures in Scheme. This work led to a development (together with Dave Musse
r) of Ada Generic Library. After a brief stint at Bell Labs, where I worked 
on a library of algorithms in C++, I moved to HP Labs in Palo Alto (1988). I
 spent the next 4 years working on storage systems: I had to learn how to pr
ogram disk controllers. In 1993 I was given a brief opportunity to return to
 my research on generic programming. STL is a result of this. In 1995 I move
d on to Silicon Graphics, where I have been trying to establish a group to w
ork on further development of STL.
  Question:
You mentioned William of Occam. William of Occam used to say "Entia non sunt
 multiplicanda" - I could translate that as "[abstract] objects are unnecess
ary". It seems that you have applied the razor of Occam to OOP. Starting fro
m algorithms rather than from objects kinds of reminds me the medieval quarr
el on universals. Is it right?
Answer:
It is a pretty analogy, but I do not think it is right. I never thought of O
O as related to a realist philosophy and I am not a nominalist at all. As a 
matter of fact, the Franciscan school: Alexander of Hales, Bonaventure and S
cotus are much closer to Augustinian/Platonist tradition. Occam was a strang
e fellow anyways. As the editor of his Opera Omnia Gideon Gal used to say: "
But the fellow was really mad!"
  Question:
For most Italian readers, the name "Stepanov" goes in pair with STL. Does ST
L mean Standard Template Library or Stepanov and Lee? And what was the role 
of D.Musser and A.Koenig in STL history?
Answer:
Well, it does really mean Standard Template Library. I did make a joke in my
 interview with Dr. Dobb's journal about STL standing for "Stepanov and Lee,
" but it was a joke. I have been collaborating with Dave Musser for almost 2
0 years. Our collaboration has been so close that it is difficult to say who
 contributed what. His is not on the list of the official STL authors only b
ecause in the short period of time when the proposal for the standard had to
 been written, he was busy doing something else. Andy Koenig is responsible 
for explaining to me the structure of the abstract C machine. STL, in a sens
e, is an application of generic programming techniques that Dave Musser and 
I have been developing to a C machine model. If it were not for Andy, I woul
d be still dealing with boxed, heap-allocated objects and pining for garbage
 collection. And, of course, Andy and Bjarne Stroustrup are responsible for 
putting STL into the standard. Meng Lee was a perfect collaborator at the st
age when it was necessary to move from beautiful ideas to a complete impleme
ntation. She kept me focused - I tend to lose interest after the problem is 
solved - if I know the solution, why bother making it known to the rest of t
he world. She was putting grueling hours into the code and the document. In 
a sense, she was the only person who believed that something practical could
 come out of the stuff; I think, that at that point both Dave Musser and I a
ctually lost hope that we could explain to anybody what we had been doing fo
r quite a while.
  Question:
What is the origin of STL? Has STL been conceived to be what it is now, that
 is "the" C++ Standard Library, or does it come from some other project? Cou
ld you tell us a history of STL?
Answer:
In 1976, still back in the USSR, I got a very serious case of food poisoning
 from eating raw fish. While in the hospital, in the state of delirium, I su
ddenly realized that the ability to add numbers in parallel depends on the f
act that addition is associative. (So, putting it simply, STL is the result 
of a bacterial infection.) In other words, I realized that a parallel reduct
ion algorithm is associated with a semigroup structure type. That is the fun
damental point: algorithms are defined on algebraic structures. It took me a
nother couple of years to realize that you have to extend the notion of stru
cture by adding complexity requirements to regular axioms. And than it took 
15 years to make it work. (I am still not sure that I have been successful i
n getting the point across to anybody outside the small circle of my friends
.) I believe that iterator theories are as central to Computer Science as th
eories of rings or Banach spaces are central to Mathematics. Every time I wo
uld look at an algorithm I would try to find a structure on which it is defi
ned. So what I wanted to do was to describe algorithms generically. That's w
hat I like to do. I can spend a month working on a well known algorithm tryi
ng to find its generic representation. So far, I have been singularly unsucc
essful in explaining to people that this is an important activity. But, some
how, the result of the activity - STL - became quite successful.
  Question:
I used to think at complexity requirements in STL as mere constraints on the
 efficiency of the implementation. You seem to imply that complexity is a tr
ue functional requirement. Is it so?
Answer:
You select different algorithms depending on complexity of the fundamental o
perations provided by the data structure. Disk and tape are functionally equ
ivalent as SCSI storage devices, but woe to the software designer who would 
attempt to use the tape as if it were a disk. In terms of STL - you can alwa
ys implement p + n for forward iterators, so why bother providing random acc
ess iterators?
  Question:
What about Generic Programming? I only found some columns by A.Koenig in JOO
P on "generic programming". Generic programming is definitively absent in mo
st C++ programming books, including Coplien, Meyer, Stroustrup, Lippman and 
so on. I think STL could be described as "Programming C++ the way you would 
never thought possible". Do you agree?
Answer:
STL, at least for me, represents the only way programming is possible. It is
, indeed, quite different from C++ programming as it was presented and still
 is presented in most textbooks. But, you see, I was not trying to program i
n C++, I was trying to find the right way to deal with software. I have been
 searching for a language in which I could express what I wanted to say for 
a long time. In other words, I know what I want to say. I can say it in C++,
 I can say it in Ada, I can say it in Scheme. I adapt myself to the language
, but the essence of what I am trying to say is language independent. So far
, C++ is the best language I've discovered to say what I want to say. It is 
not the ideal medium, but I can do more in it than in any other language I t
ried. It is actually my hope that someday there will be a language designed 
specifically with generic programming in mind.
  Question:
Could you explain to a modest C++ programmer what Generic Programming is, wh
at is the relation of Generic Programming with C++ and STL, and how did you 
come to use Generic Programming in a C++ context?
Answer:
Generic programming is a programming method that is based in finding the mos
t abstract representations of efficient algorithms. That is, you start with 
an algorithm and find the most general set of requirements that allows it to
 perform and to perform efficiently. The amazing thing is that many differen
t algorithms need the same set of requirements and there are multiple implem
entations of these requirements. The analogous fact in mathematics is that m
any different theorems depend on the same set of axioms and there are many d
ifferent models of the same axioms. Abstraction works! Generic programming a
ssumes that there are some fundamental laws that govern the behavior of soft
ware components and that it is possible to design interoperable modules base
d on these laws. It is also possible to use the laws to guide our software d
esign. STL is an example of generic programming. C++ is a language in which 
I was able to produce a convincing example.
  Question:
I think STL and Generic Programming mark a definite departure from the commo
n C++ programming style, which I find is almost completely derived from Smal
lTalk. Do you agree?
Answer:
Yes. STL is not object oriented. I think that object orientedness is almost 
as much of a hoax as Artificial Intelligence. I have yet to see an interesti
ng piece of code that comes from these OO people. In a sense, I am unfair to
 AI: I learned a lot of stuff from the MIT AI Lab crowd, they have done some
 really fundamental work: Bill Gosper's Hakmem is one of the best things for
 a programmer to read. AI might not have had a serious foundation, but it pr
oduced Gosper and Stallman (Emacs), Moses (Macsyma) and Sussman (Scheme, tog
ether with Guy Steele). I find OOP technically unsound. It attempts to decom
pose the world in terms of interfaces that vary on a single type. To deal wi
th the real problems you need multisorted algebras - families of interfaces 
that span multiple types. I find OOP philosophically unsound. It claims that
 everything is an object. Even if it is true it is not very interesting - sa
ying that everything is an object is saying nothing at all. I find OOP metho
dologically wrong. It starts with classes. It is as if mathematicians would 
start with axioms. You do not start with axioms - you start with proofs. Onl
y when you have found a bunch of related proofs, can you come up with axioms
. You end with axioms. The same thing is true in programming: you have to st
art with interesting algorithms. Only when you understand them well, can you
 come up with an interface that will let them work.
  Question:
Can I summarize your thinking as "find the [generic] data structure inside a
n algorithm" instead of "find the [virtual] algorithms inside an object"?
Answer:
Yes. Always start with algorithms.
  Question:
This mean a radical change of mind from both imperative and OO thinking. Wha
t are the benefits, and the drawbacks, of this paradigm compared to the "sta
ndard" OO programming of SmallTalk or, say, Java?
Answer:
My approach works, theirs does not work. Try to implement a simple thing in 
the object oriented way, say, max. I do not know how it can be done. Using g
eneric programming I can write:
template <class StrictWeakOrdered>
inline StrictWeakOrdered& max(StrictWeakOrdered& x,
StrictWeakOrdered& y) {
return x < y ? y : x;
}
and
template <class StrictWeakOrdered>
inline const StrictWeakOrdered& max(const StrictWeakOrdered& x,
const StrictWeakOrdered& y) {
return x < y ? y : x;
}
(you do need both & and const &). And then I define what strict weak ordered
 means. Try doing it in Java. You can't write a generic max() in Java that t
akes two arguments of some type and has a return value of that same type. In
heritance and interfaces don't help. And if they cannot implement max or swa
p or linear search, what chances do they have to implement really complex st
uff? These are my litmus tests: if a language allows me to implement max and
 swap and linear search generically - then it has some potential.
  Question:
Java is a very new language, still it lacks templates, so it prevents using 
Generic Programming. Everything must be a class. What do you think of Java?
Answer:
I spent several months programming in Java. Contrary to its authors predicti
on, it did not grow on me. I did not find any new insights - for the first t
ime in my life programming in a new language did not bring me new insights. 
It keeps all the stuff that I never use in C++ - inheritance, virtuals - OO 
gook - and removes the stuff that I find useful. It might be successful - af
ter all, MS DOS was - and it might be a profitable thing for all your reader
s to learn Java, but it has no intellectual value whatsoever. Look at their 
implementation of hash tables. Look at the sorting routines that come with t
heir "cool" sorting applet. Try to use AWT. The best way to judge a language
 is to look at the code written by its proponents. "Radix enim omnium maloru
m est cupiditas" - and Java is clearly an example of a money oriented progra
mming (MOP). As the chief proponent of Java at SGI told me: "Alex, you have 
to go where the money is." But I do not particularly want to go where the mo
ney is - it usually does not smell nice there.
  Question:
Do you think template-based programming and Generic Programming will be adop
ted by the majority of C++ programmers, or will they be confined to STL, som
ewhat like manipulators, which were never used outside the iostream library?

Answer:
I do not know. It will take a long time before the ideas behind STL enter th
e mainstream. We will know in about 10-15 years if anything comes out of all
 this.
  Question:
One thing has always amazed me, is how quickly STL was adopted by the C++ st
andardization committees. I mean, these committees are known to be very caut
ious and conservative. How do you explain that?
Answer:
The support of Bjarne Stroustrup was crucial. Bjarne really wanted STL in th
e standard and if Bjarne wants something, he gets it. He is as stubborn as a
 mule. He even forced me to make changes in STL that I would never make for 
anybody else - I am also stubborn, but he is the most single minded person I
 know. He gets things done. It took him a while to understand what STL was a
ll about, but when he did, he was prepared to push it through. He also contr
ibuted to STL by standing up for the view that more than one way of programm
ing was valid - against no end of flak and hype for more than a decade, and 
pursuing a combination of flexibility, efficiency, overloading, and type-saf
ety in templates that made STL possible. I would like to state quite clearly
 that Bjarne is the preeminent language designer of my generation.
  Question:
STL is full of creative uses of templates, such as symbolic types exported f
rom classes, or the pattern matching of a set of overloaded algorithms onto 
iterator tags. Surely enough, no standard C++ Programming book speaks about 
those idioms. How did you come to these C++ code idioms?
Answer:
I knew exactly what I was trying to accomplish. So I tweaked the language un
til I was able to get by. But it took me many years to discover all the tech
niques. And I had many false starts. For example, I spent years trying to fi
nd some use for inheritance and virtuals, before I understood why that mecha
nism was fundamentally flawed and should not be used. I am very happy that n
obody could see all the intermediate steps - most of them were very silly. I
t takes me years to come up with anything half decent. It also helped that B
jarne was willing to put certain features in the language just to enable som
e of my idioms. He once refered to it as "just in time language design."
  Question:
What do you think is the best way to teach Generic Programming and STL to C+
+ programmers? Do you think inheritance and other OO techniques should be le
arnt before, after or at the same time as STL?
Answer:
I plan to teach a course on Generic Programming at SGI. I do hope that it wi
ll lead to a book, but I am a notoriously lazy writer - I never finish paper
s unless I have a collaborator who does.
  Question:
I have done a search on Lycos for your papers and I only found two titles: t
he STL manual and a resume of you presentation of STL to the standardization
 committee.
Answer:
Well, I am lazy, but not that lazy. I probably published 20 papers and a boo
k. Many of them are on different STL sites. (Dave Musser's site probably has
 several.)
  Question:
Which book?
Answer:
The book is "The Ada Generic Library: Linear List Processing Packages", by D
avid R. Musser and Alexander A. Stepanov, Compass Series, Springer-Verlag, 1
989. It is not really worth reading.
  Question:
STL pushes C++ compilers to their limits. Contemporary C++ compilers are sti
ll unable to correctly compile some STL code. How could you develop and test
 STL?
Answer:
I do have a lot of gray hair as a result of trying to compile STL. The unfor
tunate reality is that a lot of code in the present implementation of STL is
 suboptimal because of the compiler limitations and bugs of the compilers I 
had to use when I was developing STL. Fortunately, I had help from Bjarne in
 figuring out what certain unimplemented features are supposed to do. It doe
s help a lot if you can ask the language designer what a given construct rea
lly does.
  Question:
How did allocators come into STL? What do you think of them?
Answer:
I invented allocators to deal with Intel's memory architecture. They are not
 such a bad ideas in theory - having a layer that encapsulates all memory st
uff: pointers, references, ptrdiff_t, size_t. Unfortunately they cannot work
 in practice. For example,
vector<int, alloc1> a(...);
vector<int, alloc2> b(...);
you cannot now say:
find(a.begin(), a.end(), b[1]);
b[1] returns a alloc2::reference and not int&. It could be a type mismatch. 
It is necessary to change the way that the core language deals with referenc
es to make allocators really useful.
  Question:
Could this point out a serious drawback of C++ templates? I can customize a 
class using a template argument, but different specializations are not type 
compatible. Instead, different subclasses (in OO sense) of a class are type 
compatible with the root class.
Answer:
I think that the problem is deeper than that. T* is hardwired into the langu
age. In general, I believe that it is necessary to design a programming lang
uage from the ground up to enable generic programming in a consistent way. I
 wish that somebody would hire me to do just that.
  Question:
I find two hash table implementations in the D.Musser site, and they were bo
th working and quite smart - much smarter than hash tables commonly found in
 class libraries. Why were hash tables not included into STL?
Answer:
Politics. They have to be in. Our new implementation of STL does contain the
m. In general, we need to develop a mechanism for adding things to STL. Afte
r all, STL is an extensible framework, it begs to be extended. There are man
y data structures that are missing, for example, singly linked lists, matric
es, and graphs. SGI is willing to lead the way in extending STL.
  Question:
Are you still working on STL? Doing what?
Answer:
My group at SGI, - Matt Austern, Hans Boehm and myself, - just finished a ne
w version of STL. It includes hash containers, thread safe memory allocation
 and spectacular web documentation. SGI released it into the public domain (
http://www.sgi.com/Technology/STL). We hope that we will be able to keep STL
 growing. Multidimensional data structures, persistence, multithreading are 
among the things that we plan do add. Well, it is not clear how long we can 
keep doing this stuff. There are no support from my management for any of th
e STL/generic programming activities. It is very hard to explain to them why
 SGI should pay for extensions. (It was equaly hard to explain it to HP mana
gement. They canceled my project 5 months after STL was accepted into the st
andard.)
  Question:
It seems that STL has still some drawbacks. First, HP STL is not thread safe
. Then, templates cause a lot of code to be put into header files. You canno
t have true template libraries, nor DLLs or shared libraries of (uninstantia
ted) templates: STL is mostly a compile- time library. The last drawback is 
that almost no CASE tool and no OOD methodology effectively supports Generic
 Programming. For instance, no CASE tool lets you define generic functions. 
Also, only the Booch notation is somewhat able to express templates, but res
ulting diagrams are not intuitive (to me, at least).
Answer:
SGI STL is thread safe. The acceptance of separate compilation into the stan
dard - designed by my SGI collegues John Wilkinson, Jim Dehnert and Matt Aus
tern solves your second problem. It was voted into the standard, but it will
 take a while before there are compilers that can do separate compilation. I
 do believe that separate compilation would eventually require shipping shar
ed libraries of templates. That was the main reason I initiated SGI work on 
separate compilation. It is not that difficult to design tools that will dea
l with Generic Programming. And I am quite sure that if there is some market
 for it, Grady Booch will change his notation to handle generic programming.

  Question:
One painful thing for the C++ programmer is that standardization committees 
seem to be unaware of each other. OMG has just defined a standard for distri
buted programming (CORBA), but the mapping of CORBA to C++ is unaware of STL
. They define their own set of classes, such as Sequence<T> and CORBA::Strin
g. The same problem arises for ODMG and its ODMG-93 standard for Object Data
bases. Why does this happen? Are things going to change?
Answer:
I am old enough to remember all the networking standards that were coming ou
t in the seventies. Who remembers them now?
  Question:
What could Generic Programming be in a distributed environment? Generic Prog
ramming is based on the idea that the compiler "knows" all possible types at
 compile time. This is not realistic in a distributed environment. Should we
 think at a kind of ORB integrated with a compiler? Or is Generic Programmin
g simply not suited to Distributed Programming - in that case, Java would be
 right?
Answer:
Generic Programming has nothing to do with run time vs. compile time. The pr
oblem that I find with OOP is not just that it is slow, but that it does not
 allow me to express simplest possible algorithms. Again, the signature of m
ax is:
max: T x T -> T
It is not expressible in Java, because the inheritance from some class or in
terface T changes it into:
max: T' x T -> T
You need covariant signature transformation and an ability to obtain types f
rom types, a notion of a virtual type if you like, a v-table containing type
 descriptors.
  Question:
What is an iterator?
Answer:
An iterator is a union of two theories. The first theory is a theory of name
 (handle, cookie, address). A name is something that points to something els
e. (operator*). We call it Trivial Iterator theory in our site. In addition 
to the dereferencing, it has equality defined that satisfies the following a
xiom:
i == j iff &*i == &*j
That is, two iterators are equal if and only if they point to the same objec
t. (Equality, of course, needs to satisfy all the standard axioms.) The seco
nd theory is the theory of successor operation (++i) with its refinements: s
uccessor - predcessor (++ and --) and addition (++, --, + and -) with the st
andard axioms. And, of course, pointer is just a model of random access iter
ator.
  Question:
Some argue that a pointer is a way to hack any conceivable horrible and weir
d thing into memory. Java and Delphi made it right when they disallowed poin
ters.
Answer:
Disallowing pointers that allow you to do pointer arithmetic is a good thing
. Pointer arithmetic should be allowed only where it is really allowed in C 
and C++, namely, for pointers into arrays. But disallowing pointers in gener
al is a very silly thing. You cannot get generic swap unless you have pointe
rs or references in the language.
  Question:
"category" is an overloaded word in the C++ community. How do you call itera
tor categories?
Answer:
I often call these things concepts.
  Question:
I have tried to develop a STL-like singly linked list. But I chose not to im
plement the size() member function, because I did not want the overhead of k
eeping a counter just to implement size() in a constant time, as stated by t
he C++ CD. Was it the right decision?
Answer:
size() used to be linear time in case of STL lists. It was the right decisio
n since if a user wants to keep a count it is easy to do, but usually you do
 not need it and it makes splice linear time (it used to be constant). But t
he standard committee insisted that I change it to constant time. I had no c
hoice. We will have to change this requirement eventually.
  Question:
I am studying how to express a tree into STL and I have some problems: every
 node has one father but two sons. Moving to the father could be represented
 as operator--, but I would need two different operator++ to move to the son
s. How can iterators deal with not linear structures, such as trees o graphs
?
Answer:
Even on a sequence you have different iterators. Reverse iterators are just 
one example. Stride iterators are very important and will have to be put int
o STL eventually.
  Question:
I must confess my ignorance. What are stride iterators?
Answer:
Go from i to i+5 to i+10.
  Question:
What's the difference with random iterators?
Answer:
Stride iterator is an iterator adaptor that takes a random access iterator r
ange and provides a (random access iterator) such that ++ on it goes through
 a stride (a sequence of iterator n steps apart).
  Question:
How does this relate with the problem of traversing a tree?
Answer:
I did not mean to say that stride iterators or reverse iterators have anythi
ng to do with tree traversal, but that there could be multiple iterator type
s on a data structure for different iteration orders - in case of trees pre,
 in and post order traversals.
  Question:
A frequent dilemma for me was: should I design this function as a member fun
ction or as a generic (global) function? what has been the rationale of this
 decision in STL?
Answer:
Make it global if it at all possible. It would be much nicer if begin and en
d were global - it would allow us to define them for C arrays. It would be s
o much nicer if operator* was global with the default definitions:
template <class T>
T& operator*(T& x) { return x;}
template <class T>
const T& operator*(const T& x) { return x;}
It would allow us to write:
copy(0, 25, ostream_iterator<int>("\n"));
In general, for non-iterator objects operator* should return the object itse
lf, the "meaning" of a non-naming thing is a thing itself. I would even love
 to write constructors and destructors as global functions. You could do som
e amazing stuff if this is allowed in the language.
  Question:
If I define a generic operator* your way, and in my program I define:
template <class T> class SmartPtr {
  T* ptr;
 public:
  SmartPtr(T* _ptr = 0) : ptr(_ptr){}
  T* operator*() const {return ptr;}
  // ...
};
than shouldn't I get ambiguity in this code:
int i=0;
SmartPtr<int> sp(&i);
int j= *i; // apply SmartPtr<int>::operator* or
// operator<SmartPtr<int>? both are user defined
Answer:
No, you do not. Your definition matches better (the unification is deeper) t
han the global one. That is what partial specialization is all about.
  Question:
Now, a bunch of curiosities of mine: why does not STL have something like a 
"sorted container" adaptor?
Answer:
Set is a sorted container.
  Question:
Set is not an adaptor. Why was it possible to write a heap, but not a sorted
 container, out of any container supporting random access iterators?
Answer:
Remember that it was very hard to push through STL because of its size. I ha
d to throw away dosens of useful components. (Think what happened to hash ta
bles.)
  Question:
Why is the function __adjust_heap in <heap.h> not documented ? This function
 is necessary to use the heap in the Dijkstra algorithm.
Answer:
I had great difficulty pushing heap functions into the standard. Originally,
 I wanted all auxiliary functions in STL to be visible, but it was not polit
ically possible.

Question:
It is hard for me to figure something political about a heap functions.
Answer:
It was not any particular function, but the number of them. Bjarne is person
ally responsible for reducing the number of components in STL by a factor of
 two. He was trying to make it as small as possible to placate the oppositio
n.
  Question:
Have your ever been in Italy, for business or for pleasure?
Answer:
Yes, I spent 10 days in Pisa, visited Florence and Lucca. I dream of going t
o Assisi - I am a Franciscan at heart. I cry during the second act of Tosca 
and the third act of La Traviata. I keep Dante (in Italian!) on my bed stand
. I love pasta, prosciutto and Chianti, - while I am a traditionalist, I loo
k much more like John XXIII than Pius XII.
  Question:
You must know Italian very well if you can read Dante in its original versio
n: very few Italians could!
Answer:
Well, my Italian is very poor. The way I do read Dante in Italian is by havi
ng an English translation in front of me. I read a stanza aloud in Italian a
nd then read the translation.
  Graziano: Thank you very much, Alex. I hope you will be able to come to It
aly and see Assisi soon, reading Dante in the old town of Assisi - maybe the
 most charming medieval town in Italy .
  Graziano Lo Russo has a degree in Electronic Engineering from the Politecn
ico of Turin (Italy) and is a specialist in object orientated techniques. He
 is a contributing editor to many Italian programming magazines. He can be r
eached at lorusso@infomedia.it.


--
Everybody believes that children are true,
women are beautiful and
men are strong.

※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 202.118.236.207]