Slashdot Mirror
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."
"
As a good example look at the huge problem that GNU has coming up with an english word for "free as in speech" rather than "free as in beer". The bottom line is, there is no good word - if you disagree contact GNU
This problem creates havoc in trying to explain people the idea behind free software. Sure they understand "freedom" but there is no good adjective that can be used on objects that are normally bought and sold (commodities), in the english language, to describe this freedom. Because of the lack of a word for it, it becomes much more difficult to understand - and truely limits many people into thinking that free software is something other than what it is meant to be.
Free speech == words that cost no money? If not how do you say it?
Joseph Elwell.
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
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Saw this at gamasutra.com:
:)
Toward Programmer Interactivity: Writing Games In Modern Programming Languages
But I guess this guy isn't as well known as Sweeney
Good meaty informative writing.
:)
/. and others stop posting chick-gender-divisive articles. The moment sites stop posting essays and insights and editorials by women about women for women. The day when men and women coders are human coders.
Subclassing can yield a lot of power to re-usability.
There are many caveats to subclassing implementation though.
Inheritance brings with it all the baggage of your chains of base classes. As much as you attempt to virtualize, thus yielding flexibility, you are still:
a. compiler internally generating and maintaining a virtual table of a lot of NULLs
b. the skeletal structure of the existing virtual functions or data members still define, and thus confine, your derived classes
You may gain the power to saving code from subclassing.
But then any subclassed class, which becomes someone else's base class, becomes less modifyable. Thus, in a way, a base-d class loses power.
For portability, ease of use, ease of understanding, anything which is a base class (something *any* subclass derives from) become not only self-consistent, but remain having to be concerned of intentional and unintentional behaviors (and optimization) of all of its derived classes.
A change to a base class A propagates all its changes, all its decrease in speed, all its complexity, down the chain to all its children.
Such "a complicated web we weave" makes *most* of the engine code difficult to modify and ungrade and re-use. Since changing most classes, since most of them are base classes, have too many performance or behavorial ramifications and penalties to the rest of the code.
Part of encapsulation is minimization interaction or effect of one set of code to another.
"Uncareful" or "deep" web of derivation in classes can turn encapsulation upside down.
Low level classes intended to hide or encapsulate behaviors, end up being the "weakest chain" that breaks in performance when too many vital classes are derived from them.
It is more difficult to document and comprehend such a deep weaving web.
Sometimes non-class, single interface, "flat" non-classing languages would and can ease both encapsulation, or maintainability.
To be fair to our poor DNF coders Chris, Nick and Tim, virtual class or no, it is a lot more than 4 lines of code to make magical DukeNukem.Actor's.
// OT to the "chick" thing
An example of "chick-divisive news" being harmful to women: the same site (GameSpy) requested an interview of me that I turned down.
Why?
Because the interview questions are / would be along the lines of "How is like to be a woman programmer?" "How is like to be a woman developing games?" "What insights would you have for women in game developement?" "What insights would you have for games for women?"
How in the world would I know or can speak for 50% of world population?
A Tim Sweeney, even a Seamus Blackley (Trespasser lead), never have to face questions like that.
They can discuss math, code, game, science, language.
But a woman would always be gender first, knowledge second. It shall always be more informative to know "how is it like to be a woman" from me than any knowledge I can or cnanot share with others.
The day when
Is the day when sites and interviewers will stop asking human coders like me "How is it like to be a woman?" and start asking me questions I know the answers to.
P.S. Isn't it ironic they ask a Playmate to describe Linux? And they ask a female coder "how is it like to be a woman"?
Well, not this release, anyway
We're going down, in a spiral to the ground
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.
Sapir-Whorf is wrong. It is very easy to see that language does not determine what or how you think:
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.
But I don't necessarily agree with him.
He never once considers (as far as I could tell in my admittedly hasty reading) speed issues for more advanced languages. There are plenty of fancy languages out there, but C/C++ is still the choice for power without sacraficing speed.
That said, I think more powerful constructs are very important, and I've seen several of them implemented in C++, with very positive effects.
Persistance can make managing of not only game objects (i.e. saved games become trivial) but resources very simple, since a resource file (standard formats like TGA or DXF, or your own internal formats) are just simple methods of persisting data. If your data all lives on disk in its "dead" state, it's very easy to organize and bring up what you want out of a database. It's possible to build very intelligent tools, too -- for example, developing the art and changing the game constants on top of a database that detects when you change something and loads it into the running game. Again, I've seen this system implemented in C++.
Along those lines, tools will become increasingly important as games get more complex. If you're going to run a massively-multiplayer RPG on the internet (à la Ultima Online, Everquest, etc) you need to have a crew of people there continously creating new art, models, and code, and they need to have an efficient way of doing it. Metadata about the objects in your game can let older chunks of code learn about and manipulate these objects as they are added. You can also do a lot of this in C++; the framework may be painful but once implemented there's no reason for it to be hard to use.
....
This is all well and good, but I still see a fundamental disconnect between language designers and practical programmers. Language designers are seeking elegant representations for cases that are complex in current practical languages (i.e. the mythical everpresent C/C++), but they aren't usually building "real" programs (the kind of programs you use every day) in them. There are other languages that are very practical, such as Python, or practical in theory, such as Java, but they're not particularly appropriate for games -- they're ungodly slow.
Perhaps it is time for a new language that balances hopefully a cleaner organization than C++ (perhaps dropping or at least heavily restructuring some of the more hopeless features like crazy dynamic casts and this chimaerical exception handling) but maintains the speed inherent in the language. It seems to me that game programmers are largely using a fairly safe subset of C++ anyhow; the representation changes in the language should make it easier to do the things we can now do with difficulty in C++, not make the impossible difficult. After all, that seems to be what Stroustrup was doing when he first wrote the first versions of C++ back in the early 80s.
....
You don't have to agree (except that Java sucks) and I'm not dissing PERL (but it will still never be a game language). Just my $0.02
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.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
Few people use C++ for object oriented programming. Java was a bad idea that should be forgotten as quickly as possible. UnrealScript is a special purpose language for a game; in that cases you throw out the rulebook and make it efficient for the narrow task at hand.
.c file.
The ideas in C++ and Java have been around for a long time, they've just been hyped relatively recently. They are neither the present nor the future of programming languages; they are the past: the idea of the One True Language. The present is a babel of special purpose languages, as is the future. The only difference in the future is that they will be easier to tie together.
Certainly there will be more attempts to build the One True Language, but they will fall as short of the goal as did Standard C++, Java, and Ada, and blend into the background noise.
My personal favorite programming method is to generate C (well, C++ using struct methods to shorten function names) code with Perl (while it has other uses, it stands out for me as the best quick-hack text processing language out there). If you can't express it readably with the language you've got, express it in a mess generated with readable code in another language. Perl is handy because you can dump a whole other text file into it's midst with the $var = <<'END_OF_C'; syntax.
You just use make to run the Perl script (I use the extension p2c) and redirect the output into a
I don't stick to one language when another does the job better, a typical small "C" project of mine involves 3 or 4 languages, while a large project of mine might involve a dozen or more mini-languages I wrote to express a class of GUI widgets or text-parsing details. You might want to try it, I find it very efficient.
That 5% was a concession to the handful of linguists (mostly anthropologists) who still take some portion of Sapir-Whorf seriously. In some very weakened form, the idea is still possible, but the strongest form is either unverifiable (and thus has no place in linguistic science) or has already been falsified (as the Berlin and Kay studies, among others, ultimately showed.)
A unilingual Chinese speaker is capable of understanding the notion of 'moral hazard' and can use it as well as an anglophone. Speaking Chinese is not a barrier to comprehension.
Should a Chinese economist wish to discuss the problem of 'moral hazards' in a paper in Chinese, this person will quickly find or devise a term for it and continue without difficulty, at most having to explain the notion at the beginning of the paper. The same is true of most anglophones, the majority of whom probably do not understand the term moral hazard intuitively (at least in the sense that I understand it - primarily as a term in economics) and would require that same explanation.
If this hypothetical economist wishes to show off his English, or simply because any short Chinese term he might use for 'moral hazard' implies too many unwanted connotations, he may simply plop the English term 'moral hazard' into the language. That's how 'deja vu' started. There is no reason why 'deja vu' can't be said using other terms in English - the concept no doubt existed for anglophones before the French term became current.