E. Normus Prong Wrote: > Bane Wrote: > > > bearophile Wrote: > > > > > The "Coders at Work" book written by Peter Seibel is a good collection of > > > interview to famous programmers (some parts of the book are too much long > > > and boring). In a chapter Guy Steele tells some of his ideas about > > > designing a language. He is a good programmer, he has given a significant > > > help in the development of Java and Fortress languages. > > > > > > Fortress purpose is to innovate, to be a future very hi-performance > > > Fortran designed for highly parallel computers, so its purposes are > > > partially the same of D (despite being a quite different language). > > > > > > Here are three interesting quotations from his interview that I think can > > > be interesting for the design of D too, followed by few of comments of > > > mine. > > > > > > =============================== > > > > > > From page 355: > > > > > > Steele: But I don't want to be seen as a detractor of Bjarne Stroustrup's > > > effort. He set himself up a particular goal, which was to make an > > > object-oriented language that would be fully backwards-compatible with C. > > > That was a difficult task to set himself. And given that constraint, I > > > think he came up with an admirable design and it has held up well. But > > > given the kinds of goals that I have in programming, I think the decision > > > to be backwards-compatible with C is a fatal flaw. It's just a set of > > > difficulties that can't be overcome. C fundamentally has a corrupt type > > > system. It's good enough to help you avoid some difficulties but it's not > > > airtight and you can't count on it. > > > > > > ----------------- > > > > > > For Fortress a C-like type system can't be enough. I don't know what > > > Steele thinks about D type system and the way it is used. > > > > > > =============================== > > > > > > From page 361: > > > > > > Seibel: So are there language features that make programmers--folks who > > > have mastered this unnatural act--more productive? You're designing a > > > language right now so you've obviously got some opinions about this. > > > > > > Steele: I said earlier that I think you can't afford to neglect > > > correctness. On the other hand, I think we can design tools to make it > > > easier to achieve that. We can't make it trivial, but I think we can make > > > it easier to avoid mistakes of various kinds. A good example is overflow > > > detection on arithmetic, or providing bignums instead of just letting > > > 32-bit integers wrap around. Now, implementing those is more expensive > > > but I believe that providing full-blown bignums is a little less > > > error-prone for some kinds of programming. A trap that I find systems > > > programmers and designers of operating-systems algorithms constantly > > > falling into is they say, "Well, we need to synchronize some phases here > > > so we're going to use a take-a-number strategy. Every time we enter a new > > > phase of the computation we'll increment some variable and that'll be the > > > new number and then the different participants will make sure they're all > > > working on the same phase number before a certain operation h! appens." And that works pretty well in practice, but if you use a 32-bit integer it doesn't take that long to count to four billion anymore. What happens if that number wraps around? Will you still be OK or not? It turns out that a lot of such algorithms in the literature have that lurking bug. What if some thread stalls for 2 to the 32nd iterations? That's highly unlikely in practice, but it's a possibility. And one should either mitigate that correctness problem or else do the calculation to show that, yeah, it's sufficiently unlikely that I don't want to worry about it. Or maybe you're willing to accept one glitch every day. But the point is you should do the analysis rather than simply ignoring the issue. And the fact that counters can wrap around is a lurking pitfall that doesn't hurt most programmers but for a very few it lays traps in their algorithms. > > > > > > ----------------- > > > > > > From what he says it seems that multiprecision integers (like the ones > > > you can use in Python, CLisp, etc) have to be the default integer type in > > > a language, because (as I've seen using languages that are able to catch > > > integer overflows) they are safer. > > > > > > The smart compiler can replace multiprecision numbers with fixed-sized > > > ones everywhere it can demonstrate they can't overflow. Then the > > > programmer can profile the code and replace the multiprecision ones with > > > fixnums in the spots where (and if) he/she/shi experimentally sees the > > > performance is not good enough. And even in those spots in non-release > > > mode the code can test for overflows at runtime. If well implemented > > > (this means they are fully stack-allocated unless the numbers become > > > quite large, as in Python 2.x) this can be a way to avoid some bugs. > > > > > > =============================== > > > > > > From page 356-357: > > > > > > Steele: I think it's important that a language be able to capture what > > > the programmer wants to tell the computer, to be recorded and taken into > > > account. Now different programmers have different styles and different > > > ideas about what they want recorded. As I've progressed through my > > > understanding of what ought to be recorded I think we want to say a lot > > > more about data structures, we want to say a lot more about their > > > invariants. The kinds of things we capture in Javadoc are the kinds of > > > things that ought to be told to a compiler. If it's worth telling another > > > programmer, it's worth telling the compiler, I think. > > > > > > Seibel: Isn't most of the stuff in Javadoc, other than the human-readable > > > prose, actually derived from the code? > > > > > > Steele: Some of it is. But some of it isn't. Relationships between > > > parameters are not well captured by Java code. For instance, here's an > > > array and here's an integer and this integer ought to be a valid index > > > into the array. That's something you can't easily say in Java. That's an > > > important concept and in Fortress you are able to say such things. > > > > > > Seibel: And they're compiled into runtime asserts or statically checked? > > > > > > Steele: Whatever is appropriate. Both. In the case of Fortress we are > > > trying to be able to capture those kinds of relationships. We talked > > > about algebraic relationships earlier, the idea that some operation is > > > associative. We want to be able to talk about that very explicitly in > > > Fortress. And I don't expect that every applications programmer is going > > > to stop and think, "You know, this subroutine I just invented is > > > associative." But library programmers really care about that a lot. > > > Partly because if they're going to use sophisticated implementation > > > algorithms, the correctness of the algorithm hinges crucially on these > > > properties. And so where it does depend crucially on those properties, we > > > want a way to talk about them in a way the compiler can understand. I > > > conjecture that that is an important approach to finding our way forward, > > > to capture in the language important properties of programming. > > > > > > Seibel: What about the role of the language in making it impossible to > > > make mistakes? Some people say, "If we just lock this language down > > > enough it'll be impossible to write bad code." Then other people say, > > > "Forget it; that's a doomed enterprise, so we might as well just leave > > > everything wide open and leave it to the programmers do be smart." How do > > > you find that balance? > > > > > > Steele: The important thing is just to realize that it is a trade-off > > > that you make. And you can't hope to eradicate all bad code. You can hope > > > to discourage certain kinds of likely errors by requiring "Mother, may > > > I?" code; in order to do something difficult, you have to write something > > > a little more elaborate to say, "Yes, I really meant this." Or you can > > > purposely make it difficult or impossible to say a certain thing, such > > > as, for example, to corrupt the type system. Which has its pluses and > > > minuses--it's really hard to write device drivers for bare metal in a > > > completely type-safe language just because the levels of abstraction are > > > wrong for talking to the bare metal. Or you can try to add in stuff that > > > lets you say, "This variable really is this device register at absolute > > > address XXXX." That in itself is a kind of unsafe feature. > > > > > > ----------------- > > > > > > Integer assured to be inside the range of indexes of an array: in D2 such > > > indexes are less common compared to C (thanks to foreach, higher level > > > functions, etc), but it seems a good idea. > > > > > > A way to tell the compiler that a function (that takes two arguments) is > > > commutative or associative: this sounds like a nice idea. It looks > > > similar to the the pure/@pure attribute of D2, so the syntax is easy to > > > invent here, @associative and @commutative :-) But I guess it's less easy > > > to teach the compiler how to use such such annotations. > > > > > > In C++0x one of the advanced purposes of the Axioms > > > (http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29#Axioms ) was to be > > > able to tell the optimization stages of the compiler some invariants like > > > that one. In the meantime the iedea of adding Axioms to C++0x is delayed > > > of refused. In practice I think that you can gain most of the purposes of > > > Axioms with a less general approach, because most times you don't need > > > that full generality, and implementing it in the compiler looks hard. > > > This means that having just few built-in annotations like @associative > > > can be enough for many purposes. > > > > > > Giving the language a way to move some more semantics from comments (or > > > the programmer head) to the code is generally a good idea, and I think > > > it's something that will be done more and more in languages of the > > > future, but you have to be careful to not turn the language into > > > something too much complex and fussy to use (as Cyclone), finding a good > > > balance between requiring that extra semantics annotations everywhere and > > > make them useless. CommonLisp shows a possible strategy to do this: when > > > you compile a program or just a function at max optimization level, the > > > compiler gives you a list of the spots where it is missing optimizations > > > because it lacks the necessary semantics. So the programmer can add the > > > semantics, type annotations and other annotations in those spots, and > > > increase the the code performance. > > > > > > Bye, > > > bearophile > > > > Hm, Guy Steele sounds like porn actor name. Interesting article, dough. > > Leave Guy alone - we all have to make a living...
So he's programming during day and acting over night? Man, that is perfect job!
