Tim Sweeney On Programming Languages

Fargo writes "GameSpy posted a six-page essay of Tim Sweeney's entitled "A Critical Look at Programming Languages." Tim Sweeney is, of course, the lead coder for the Unreal game engine (one of the most licensed 3D game engines for the PC.) Juicy quote: "We game developers hold the keys to the future of hardware and software technology... Games were responsible for creating the market which enabled 3dfx and NVidia to mass-product $100 graphics chips which outperform $100,000 Silicon Graphics workstations. In terms of technological progress, we game developers are way more influential than most of us realize." "

Comments

ignorance

[mcc]

i am shocked by the incredible ignorance displayed in this article, by the way it covers such a tiny division of the programming languages in wide use, and such bad languages at that. This person seems to think that everyone in the world uses obscure, cumbersome languages like C, C++, objective C, java, perl, lisp, PHP, Bash, FORTRAN, Cobol, Forth, smalltalk or some form of assembly. What an isolated world this person must live in! He seems to have some extreme bias toward use of functional programming languages.

Specically i am very annoyed by the total lack of any discussion of INTERCAL, umlambda, or orthogonal--what i feel to be the most important languages out there, especially for games. None of these were even mentioned! Why would you write an first person shooter in C++ instead of INTERCAL? Why, as far as i'm aware there isn't even opengl available for c-based languages!

If you don't like these three above for some silly reason, at LEAST use Forth. any language where you can't redefine the value of four is for wimps. Or use Visual Basic-- its usefulness, portability, flexibility and sheer power are unparalleled. (i'm sorry, that last bit was a little over the top, wasn't it?)

-mcc
hmm. that reminds me, i need to learn objective c..
2B OR NOT 2B == FF

One nit to pick

[vlax]

The first few paragraphs about human language - basically the idea that your language restricts what and how you can think - is about 95% false.

It's called the Sapir-Whorf hypothesis (although there's some debate as to whether either Sapir of Whorf had anything to do about it) and is not widely held to be true among linguists. It occaisionally comes up in the literature, mostly to trash it.

Therefore, it is not a recurring theme in any literature about linguistics written by actual linguists of the last 30 years.

As for the contention that programming languages limit what kinds of programs we write, I am sceptical, but not so dismissive. Certainly I hate writting code to do lots of complicated string handling in C, prefering perl or java for the job. However, by building my functions carefully I can do it in C, and in fact have. I would balk at doing the same kinds of programs in assembly language.

That, however, seems mostly to be a question of finding the right tool for the job. If the next generation of languages allows me to abstract these differences and use one language with different toolkits (in principle I suppose this is possible with today's languages), I'm all for it.

thought != language, natural or formal

[MattMann]

I knew that article was off to a bad start when he didn't refer to "natural" and "formal" languages by their official names. But this early post got it mostly right, but lacked examples so too many people got distracted by that obscure philosophical discussion. Here are some examples that I think make the points vlax was attempting.

Sapir-Whorf is wrong. It is very easy to see that language does not determine what or how you think:

• When you can't remember a word, you know exactly what you want to say, you just can't get to the word
• People who suffer from aphasic brain damage often lose entire vocabularies (all the colors, for example) but they don't lose the ability to see and think about the concepts
• Deaf people don't learn their native" language, and yet, they can think perfectly clearly, and
• deaf Frenchmen are just as clearly "French" as other Frenchmen (tant pis? :)

Russians have no word for fun? I doubt it! But, if they don't, it means they have no sense of fun. But in that case it's the culture influencing the language, not vice versa. English had no word for chic, but we knew/learned the concept so we borrowed a word from French. Our culture considers French culture to be chic and so do the French. But that's why they had a word for it: that's the culture talking. Eskimos have 32 words for snow (myth, I know) because they need them to succintly describe the snow they encounter. English could add those too, if it needed them, just like cross country skiers quickly learn the names of the different waxes they need to use. It's pretty overwhelming: thinking takes place underneath the veneer of language.

programming languages need not limit what kinds of programs we write

This "string handling in C" counterexample is a small one. Full object-oriented programming is easily accessible in C. When you typedef a struct (let's use "Shape" as the example), include an array "data member" (hint: call it vtable) which is pointers to functions. Use NewShape() instead of malloc to create one, and have NewShape initialize the vtable with pointers to functions like PrintShape. Create a "circle" struct, and have NewCircle first call NewShape, then depending on how you initialize its vtable, you can have inheritance, virtuals, polymorphism, etc. There are small syntactic differences: instead of circle.PrintObj(), use PrintObj(circle), though you could use C's awkward function pointer syntax. Passing the obj as an arg is what C++ does underneath anyway. if you think that this is not OOP, you need to learn to think abstractly. There are some differences of course: this way lacks destructors (like Java) but it can solve the multiple inheritance "problem" by being explicit about the semantics.

the weakness of the analysis in the article can be seen in the table. Look across the columns... object-object-object? That axis has little to distinguish it. Most of what he says is not outright wrong, can even be insightful, but still so much is severely lacking. For example, I understand his "procedural" programming paradigm and why he is tempted to lump fortran and C together, and yet fortran can't conveniently be object oriented in the way that I describe for C.

Other reasons to idolize Tim Sweeny

[Pascal Q. Porcupine]

I think it's safe to say that quite a few CS geeks have been brought up to more modern programming practices thanks to Tim Sweeny's earlier work, most notably ZZT. ZZT wasn't much of a game on its own; where it shined was the fact you could extend it by writing your own games, since it included an object-oriented message-passing trivially-multi-tasking scripting language of its own, including a rather cool IDE. I learned quite a bit of high-level programming stuff simply by toying with this rather low-level interface; I learned about message-passing, parallel processing, deadlock-avoidance, and object-oriented programming in general thanks to sitting in front of my old 286 with Hercules monochrome into the wee hours of the night. I even learned about bad interface design by playing a lot of other peoples' games which assumed that I had a color display.

I personally think UnrealScript is a sweet language, and I can't wait for Unreal binaries for Linux (so that I can finally play and create with Unreal, which I purchased so long ago). Even if I never get around to that, the principles behind it are what drive my thoughts for a 3D MUCK system I'm working on in what passes for my spare time.

Back in the "good old days" when Epic Megagames was Potomac Computer Systems, I exchanged snailmail with him all the time. Every now and then I'd send him some program I was working on, and he'd send me a beta of whatever game he was working on (I was probably one of the first people on the planet to have, and beat, the first episode of Jill of the Jungle); one time he even gave me the registered version of ZZT. I still have that around somewhere, though it's kinda hard to use it since it's on a 5.25" disk. :)

In any case, I just wanted to publically express my thanks to him here. Once upon a time I emailed him directly and he was obviously very busy (Unreal was "about to come out;" this was a couple years before it finally did :) and I doubt he's gotten any less busy nowadays.

I wonder if there's been any thought of writing a portable ZZT engine clone... anyone know of any good ZZT game archives? (Yeah, I know ZZT itself is free(beer) now, and would be free(speech) if the source code weren't lost... I'm too lazy to get dosemu working again though. :)
---
"'Is not a quine' is not a quine" is a quine.

Re:Sweeney quote: Microsoft Word

[SheldonYoung]

Tim paints himself into an interesting corner. He argues faster machines should not be required, yet he years for more and more abstraction.

Abstraction is great for design and programming speed, and not good for executable speed. It's the trade off we make, and one of the biggest reasons applications are bigger and slower and better than ever.

His C=A+B argument is a good example. The function which adds an element of A to an element of B incurs overhead because it is a function. If you make special allowances for the list-of cases then you have just undid the abstraction. Yes, optimizers can do good things, but they only work so far.