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."
"
I think Sweeney's got some really, really good ideas here, especially as far as virtual classes. I can see that being very useful in the future. I wonder if there are any languages currently in development that take advantage of any of the features he was talking about.
I'm fairly new to perl, but It seems to me that perl does SOME of the things he talks about for "language of the future".
At the very least, I now have a compeling reason to learn UnrealScript.
-------- "All I want in life's a little bit of love to take the pain away" --Spiritualized
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
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.
My father has argued for years that the ``real purpose'' of the personal computer is gaming. Everything else is just an excuse to develop and buy these fabulously expensive toys.
For a long time, I thought it was a pretty funny joke, but a couple of years ago I realized that he was exactly right in a very real sense. No other market drives the demand for powerful hardware as much as the game market. There are few applications that really demand such high processor speeds or bus clock rates or monster graphics cards, and those applications tend to be special-purpose high-end professional tools like CAD or scientific visualization software. Gaming is an end-user luxury market, and is the chief reason for the constantly increasing bleeding edge of the computer hardware market.
It's true. The real reason that the personal computer exists is so that we can play games. It's very fortunate that we have been able to construct this multi-billion-dollar industry to hide that fact.
Eiffel is the object oriented language at the forefront of object oriented development. It's not widely used, but whenever a new concept in object oriented computing comes around, Eiffel incorporates it. I don't know enough of Eiffel to know if it supports "virtual classes" yet, but I'm sure if its doesn't that its only a matter of time...
It does include something that will probably get included in whatever language comes down the pike in the future (and there are ugly hacks that try to do these things in C++ and Java that people actually SELL)... Design By Contract is one, and incremental compilation built into the language is another. The Design By Contract is where the gold is for me (then again I've never made a single change to a program and had to wait 2 hours for a recompile)... once the source code is done in Java and C++, once your classes are frozen and done, you have to write documentation. With Eiffel you just hit the "generate short form" button and it generates an astounding amount of information for your classes, variables types, bounds, everything. And it does it in every format imaginable. Setting hard code-level bounds on variables with a single keyword is golden, setting down the bounds of things being passed into a method and the things going out of it is wonderful.
Even better is that 99% of these really high level features cause NO code bloat, they're to speed debugging, facilitate actual code reuse, etc.
How many people do you know in C++ that are actually comfortable and practice the "black box" theory of classes?
Esperandi
You speak English (I assume you're unilingual, if not, imagine the many folks on /. who are) yet you can clearly understand the difference between 'free as in speech' vs. 'free as in free beer.'
Your language has obviously not restricted your ability to think in this respect. Someone, somewhere, once upon a time, explained what they meant by 'free software' and now you have no trouble thinking clearly about it. The lack of a simple translation has no impact on your ability to think.
As I read it he says:
Programming models change every ten years
Indisputable
They seem to change for the better
Yup. So far.
C++ is not a bad language, but it's too big
Damn right.
But I think he dismisses the STL architecture too readily. It is an amazingly good abstraction, easy to extend (not that you need to often) and avoids being too object-oriented (which would have made it ridiculous)
Java is a good language, but it's slow
Yup. Again
UnrealScript rocks (but not enough)
Never used it. However good it is, can I model a telecomms network with it?
I also I think he skipped a bit to briefly over the 'Groups of Objects' technologies (patterns etc).
The fundamental problem is that we don't think in terms of 'language' (human or computer). We think with ideas. Computers 'think' with binary operations. I suspect that the reason so many people find computers difficult and scary is that they don't know how to translate their ideas into terms the computer will 'understand'
As an example, I get paid to develop software. Mostly I do architecture rather than programming. When I am designing a system I use paper, pens and whiteboards. When I try and transfer the design to an 'electronic' format, I struggle. The tools don't exist. Why not? The tools I use are very good, but I find it difficult to express my ideas with a screen, mouse and keyboard. I spend too much time second-guessing the tool programmer, thinking 'How would the programmer have expected me to this?' - I shouldn't have to concern myself with this (mostly I don't - I shout for the tools programmer to show me how to do it)
To end this tedious rant:
Yes, we need to rethink programming models constantly
No, there is 'No Silver Bullet'
Human/computer interaction systems are a disgrace to us all. Please will somebody make a computer as easy to use as a pencil and paper. I'll help.
An Nvidia GeForce/quadro kicks the crap out of a $100k+ SGI reality engine on just about any test you could devise.
The reality engine is quite a few years old, and its follow on, the infinite reality and IR2 still have some honest advantages. You can scale them with enough raster boards so that they have more fill rate, and they do have some other important features like configurable multisample anti-aliasing and 48 bit color.
Even now, lots of applications can be compiled on both platforms and just run much better on WinNT+nvidia than on the best sgi platform available. Having a 700mhz+ main processor helps, irrespective of the graphics card.
Some people still have a knee-jerk reaction that claims that "real applications" still run better on the high end hardware, and there are indeed some examples, but the argument bears a whole lot of resemblence to the ones put forth by the last defenders of ECL vector supercomputers.
Most people's applications don't show advantages on high end SGI hardware.
The big issue is the pace of progress -- SGI aimed for a new graphics family every three years with a speed bump in between. The PC vendors aim for a new generation every year with a speed bump at six months.
John Carmack
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"?
Sweeney gave some good unspoken advice, That is to say, keep learning new languages. Check out "The Pragmatic Programmer" [2000 Hunt, Thomas.] You can find it in any good bookstore.
The book has some useful advice on the practice of programming. Things like "How not to be stuck programming in a dead language." (I'm paraphrasing), and it expands upon the concepts that Sweeney mentioned, like orthogonality.
Just a little extra material, if you bought the gospel the Sweeney was preaching. Otherwise...
Comments from a deranged lunatic who thinks he's cleaver.
Well, not this release, anyway
We're going down, in a spiral to the ground
Yes, we've been working on ZZT engine workalikes for some time now. I've done a good bit of work on the subject. In my document The ZZT File Format, I have a lot of detailed information for anyone interested in working with ZZT files.
:) Part of this has been my ever-evolving libzzt, which is almost working now.
:)
I've also been working on various other ZZT projects. I see JZig has pointed out my attempts at combining OpenGL and ZZT (he missed a picture). I dunno how well this will work out due to performance issues -- it's a lot more polygons than you think in those ZZT screens
If you're interested in helping development (or any other slashdaughters for that matter), I could eventually clean this stuff up and put it up on sourceforge...
The other ZZT clone project of note is ZZT++, a C++ reimplementation of ZZT. It's very DOS centric, but the source is GPLd, so it doesn't have to stay that way. See zzt.org for general ZZT info and news (or trap.cx/zarchive since zzt.org seems not to be resolving)
That enough ZZT info for you?
- k e v
F0 07 C7 C8
There's an interesting aspect of openness going on here: Education, and a slow but steady ramping up of the "coolness" of highly technical skills.
Medicine is cool because you can save lives. Acting is cool because lots of people enjoy your work. Programming, over time, will become more and more cachet as A) It remains difficult to master but simple to begin(something neither medicine nor acting can ever approach), B) Budding programmers realize the value of an audience interested in what they personally have to say, to teach, and to create, and C) The end result is frantic appreciation from either businesses(Linux developers) or the 14-30 gaming crowd(Game programmers).
Appreciation is a good thing.
About Sweeney's paper(truly excellent, incidentally), a couple things come to mind. He talks about the concept that "C=A+B" should be equivalent to C[n]=A[n]+B[n] -- in other words, take the first value of the A array, add it to the first value of the B array, and then put that in the first element of the C array. After all, that's what C=A+B obviously means, right?
I don't know about that. Perl thinks C=A+B would expand to "C is the A list with the B list tacked on at the end". The add is one dimensional, not two dimensional--the two lists are glued together, not mixed into a sum. I think that's rather logical.
And what of another perfectly logical explanation? Maybe C is meant to be a single integer. Now you take all the ints in A, and all the ints in B, add 'em all up, and put 'em in that C value.
Perhaps we need more punctuation, more symbols to describe the differences--we could have +, ++, +-+, +++ATH...that's the solution Perl found, and it's Perl's biggest albatross--too much dense punctuation.
Perl without Punctuation is like Programming Without Caffeine.
Of course, as long as you know there's something you don't understand, you can look it up. But if you think you know what C=A+B is "obviously" doing, when in reality it's doing something completely and utterly different, you're going to have a much harder time debugging your code. Not knowing what's broken is possibly the single most expensive debugging scenario possible, by any measure.
Stop for a second and ponder the power of such a concept -- with about four lines of code, you've sub-classed a 150,000 line game engine and added a new feature that will propagate to several hundred classes in that framework.
This sounds really, really cool, but...
How predictable can a system where this occurs be? Would we map destinations of modified code? Don't you usually get problems when new features are bolted onto old architectures when really the old methods need to be wholly rewritten?
Of course, these are problems that have stricken *every* advance in language design...there's always the optimization that becomes impossible as you go up the ladder.
The most desirable approach is to have language-level security, where the compiler can usually tell you "that's not allowed" rather than determining security violations at runtime--that approach allows the maximum amount of optimization compared to the brute-force kernel transitions of operating system security.
Sweeney's awesome, and I respect him highly, but this is probably the biggest error of the entire piece.
Yes, it'd be nice to be notified *as the programmer* that your code violates a security constraint--in fact, it'd be beautiful, because then you'd have line-level notification of where your code is misbehaving in ways that would compromise the security of the host machine. (The concept of "Buffer Overflow Waiting To Happen on Line 12431" just appeals to me.) But, um, that presumes that the programmer doesn't *want* their to be a buffer overflow, or a kernel backdoor, or whatnot. Put all security in the compiler, and a malicious entity will simply compile the code on their compromised OS, move the binary over to a target machine, and grab themselves a rootshell.
Clearly, this isn't an optimal scenario.
Now, you do have situations like the JIT compilers for Java Bytecodes that go to some length to verify the validity of a bytecode before compiling it, and may(I'm not sure, and this probably varies by implementation) lock off entire branches of functionality through the compiler. But that's different--the code must pass through the compiler *on the host machine* to be converted to machine language. In effect, the end binary is a combined product of the bytecode and the host-controlled compiler. If the system designer wishes to have a userspace process handle extensive security analysis before passing a binary off to be executed, that's one thing. Trusting binaries from arbitrary compilers is quite another!!
And, it remains the unfortunate truth that there are more professional Cobol programmers than C programmers, more C++ programmers than Java programmers, and for many years there will be more Java programmers than there are followers of the successor language.
I've been thinking about this, and as languages have gotten "cooler", I think there's something to be said about a loss of stability. I don't think anybody is surprised if a COBOL based billing system doesn't go down for a year; I also doubt most people are surprised if a Java applet manages to trash their web browser within a period of minutes.
Something's wrong there.
Maybe the reason there are still COBOL programmers around is that few C, C++, or Java based systems could remain acceptably reliable after 25 years?
In terms of technological progress, we game developers are way more influential than most of us realize.
I noticed. I've been saying this for years: John Carmack is damn near personally responsible for Intel's dominance. Had Quake not been so perfectly tuned for Intel's Pentium processors--and thus so amazingly unoptimized for AMD's and Cyrix's competing x86 processors--Intel would have taken severe hits in either market share or year end profits over the last five years. For all the talk about the genius of Andy Grove--and don't get me wrong, I'd probably bungee jump off the Grand Canyon for a chance to have dinner with the man--it was John Carmack's low level pipeline optimizations and hyperusage of the floating point capabilities of the Pentium architecture that directed quite literally billions of dollars of purchasing decisions away from AMD and Cyrix into the waiting arms of Intel.
3Dfx's long term dominance in the 3D market was a similar scenario--the fact that Unreal hasn't played all that well on anything *but* a 3Dfx card until rather recently played no small part in their dominance.
game developers are in a unique position, by virtue of starting projects anew every 2-3 years, to "short circuit" the process and radically accelerate the adoption of cool new technology.
The best language in the world ain't going anywhere without top notch compilers that the gaming industry isn't going to write. This, more than anything else, is the biggest problem that game developers have if they want to choose new languages. A handful of games a while back were written in Java, using Asymmetrix's Java Flash Compiler(amazingly cool tech, really. You could recompile the code of a running app, and *it wouldn't stop running*. Then you could actually compile and release x86 binaries of your code. Never made it to Java 1.1 *siiiigh*)...none of 'em did all that well.
There's another issue to consider--game developers are truly writing less and less of the low level code. This is a good thing--who wants to write Yet Another Sound Mixing routine when you can just toss another wave at the sound device--but it does create some constraints against spawning new languages. It didn't used to be that hard to change languages--you were rewriting everything, after all. Now, you're talking about every single game shipping rife with dependancies on external sound libs, 3D rendering drivers, input systems, socket code...
Yes, there's always translation layers, but that kills half the gain.
Tim, if there's one question in this entire piece that I'd like you to reply to, it'd be this:
Network effects--the fact that a given standard gets exponentially more valuable as others share in that standard--have essentially locked TCP/IP as the internetworking protocol of choice for the foreseeable future, to the point where even upstart additions such as IPv6 and IPSec are finding acceptance to be a difficult task.
Could the same fate befall any new kinds of advanced programming languages, the identities of which were notably and painfully absent from your essay?
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
(Also posted to GameSpy's forum)
I'd like to see Tim explain just how it is that functional languages are confined to the realm of theory, considering the infinity of real-world applications in which they have been used since Lisp's inception in the late 1950's. (You do remember that Lisp is one of the oldest programming languages still in use, don't you?) Even more so when you consider the roots of the thing that Tim touts as one of the next big things: "parametric polymorphism", which is nothing but a (poor) adaptation to the imperative paradigm of a subset of Haskell's type system.
Perhaps this is a matter of taste, but I tend to dislike strawmen, especially when attempted by this kind of engineer, who, for some reason, seem to have a dislike of anyone who even sounds like a computer scientist (the keyword here being "scientist"). Face it, Tim: simply sweeping all which doesn't conform to the New Jersey mindframe under a blanket of "purely theoretical languages that have no use in the real world" won't make it true. The fact is that, as long as we're discussing what programming will be like in the future, functional languages are far beyond the state-of-the-art from New Jersey. (Even other game developers recognize this, as evidenced in a mid-1999 article on Gama Sutra about Haskell and other languages in gaming.)
For a glimpse of the real future of programming (as well as computing in general), I suggest the TUNES project, of which I am a member.
(By the way, Tim would have you believe that C was the very first structured programming language. I laughed especially hard when I read that part of the article.)
To the editors: your English is as bad as your Perl. Please go back to grade school.
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.
When I started out in programming 31 years ago [mumbled the old geezer ;-)] I bought Jean Sammet's classic book "Programmi ng Languages:History and Fundamentals", a two-inch thick thing with not overly detailed descriptions of nearly a hundred programming languages. I've actually managed to work in over a dozen of those, as well as several modern ones, and about 20 assembly "languages" - it's been a while since I counted those separately, as nowadays one thinks of a single Assembly language with trivial variations for each CPU or MPU. Nearly all of those languages are extinct, I suppose. Remember, for instance, the Algol 68 disaster? An evolutionary dead-end which advanced compiler theory a lot, but has no descendants today... I could go on for a couple of pages, but will spare you.
That said, I think the author's conclusions are valid for his chosen field - games for desktop computers. In embedded systems, C++ or even C is a perfectly valid way to go, since one usually has either the whole source avaliable and compiling/linking together, or one has reasonably static library components. And in the smaller MPU/MCU universe, one is back in the olden days of 8K code space, 128 bytes of RAM, and bit-twiddling to save space or time...
Regarding the non-games desktop arena, I definitely think that some evolution of NeXTstep (aka Apple's Cocoa) will point the way for the next 10 years. I'm starting to learn that now, the learning curve is a little steep, but it's very powerful stuff.
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 had a look at this document expecting to find loads of stuff to to contradict but instead I find a well writen article and my respect for Tim Sweeney growing. It's all to common particuarly with games programmers for these kinds of documents to be little more than a grind stone for a given set of ideas. Most of what is said concerning the development of programming languages is easy to agree with although the type of language construct he is talking about may be a little far of than he realizes.
For a long time their has been the argument of which weather or not C++ is slower than C, in reality C++ is slower in some situations, in others it is no diffrent from C. In 'C' a variable is a variable and a function call is a function call, in C++ and other OO languages functions can be virtulized (without you realizing it) createing extra layers of indirection. A 50k line peice of software using all your latest multiple inheritance, operator overloading etc. my be easier to develop and debug debug next to the 200k line pure 'C' version, but there is a good chance all that extra function call overhead and indiretion will total up into a signifcant performance hit. Aside from applications like games where processor load is high and performance is near the top of priority list language discisions become a little more vague. Richard Matthias makes a convincing argument in favour of laguages like Visual Basic in this article. In games however, as the article correctly states performance is the key, the kind of functionality Tim is looking for is going to produce even indirection etc. That's not to say it won't happen, after all one of the things I have noticed in the latest generation of x86 processors is that indirection and function all overhead seem to be less of a performance drag.
Most of the other things we deal with like the hardware accelerators, processors and development tools have changed radicly in the last 5 years but we are still using the same programing laguages, so prehaps it is time for the language department to catch up.
Tim has a point on a few things, but notably about how important game developers are to the PC. Although he is a little bit in left field with his $100 graphics chip vs. $100K SGI, he is close. Without gaming and its inevitable push, 3D on the PC would not have happened. Sure there were proffessional OpenGL cards before gaming cards came out, but how did they perform, and where would they be today? It is proven that consumer technology moves significantly faster than corporate and high end technology. I seriously doubt that the high end OpenGL cards on the PC, such as the Intergraph Wildcat 4000, would be as fast as they are without the competition from consumer cards. (Face it, would you want to release an OpenGL card for $2K when a 3Dfx was a quarter the performance, but only $200?) The proof is this. The Quadro GPU is faster than a wildcat at about half the price. Why? Because it is based on the lightning fast GeForce consumer card. Do you really think that Intergraph is going to sit on its ass, or are they going to develop a card that blows it away?Secondly, gaming has pushed the processor and multimedia subsystems to increadible levels. All the technologies that make a PC competitive with a low or mid end SGI, such as AGP, PCI, SDRAM, the new intel multimedia hub, SSE, 3DNow!, etc, are mostley pushed by gaming. (Yes, SDRAM is a gaming technology. It features much lower latency than FPM. Latency really isn't important in image editing or word processing, but is critical in games. Same thing for PCI. ISA graphics cards were plenty fast for word processing.) You can trace gaming's influence even farther than these reletivly new technologies. I seriously doubt that PCs would ever have been seen as a multimedia machine (a term that got coined in the early 486 days.) without gaming. They were the first "multimedia" apps out on PCs and the ones that continued to push technology. The fact that they pushed technology is also important. Do you need a 800 MHz athlon to word process, watch movies, or even photo editing ?(I mean cleaning up old pics, etc.) But you do need it to play quake. So while other technologies have come onto the PC because of its increasing power, the PC would not have that power if games had not pushed it there. (or it would have been much slower to come around.) Of course everyone benifits from that power. The PII was designed to play games (and to a lesser extent to do multimedia), but it still make a damn good server. I often see on slashdot, though people who think that games aren't "real" apps. Or that a server is a "real" computer. I've heard people say things along the lines of, "who needs games on Linux, go out and do some REAL work." Well, sorry to bust your bubble but games got the PC where it is, and all the gamers, everyone who has ever used a multimedia application, all the people who used to have to buy a $20K SGI to do their graphics work but now can buy a $3000 PC, and yes, even all the sysadmins who saved $15000 by not having to buy a SUN, owe game developers.
A deep unwavering belief is a sure sign you're missing something...
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.
Does he not see that binary platform-independence in Java led directly to its performance problems? Even with hacks like JIT compilers, performance of bytecode lags well behind binaries compiled from Java. This is just one of many examples that illustrates a common principle: at every level of language advancement, there's going to be some performance tradeoff.
The best example of how this affects programmers is the Quake 1 engine. Released before mainstream hardware acceleration, the most processor-intensive routines in the engine are written in assembler, and just about every possible performance/elegance conflict is resolved with performance in mind. The result? We all played Quake with 35 fps on a Pentium 166 in 320x200 software mode. In the newly released source code, rewriting the assembler in C drops performance by close to half. With today's machines its not a problem, but back then I don't think anyone would have enjoyed playing Quake too much with sub-20 fps.
But then he goes on to lay out what he sees as the major shortcomings of current generation languages, which really comes down to:
- The distinction between primitives and objects (especially the lack of easy manipulation of objects a la primitives), and
- The lack of uber-classes.
Let's go back to the article: "Stop for a second and ponder the power of such a concept -- with about four lines of code, you've sub-classed a 150,000 line game engine and added a new feature that will propagate to several hundred classes in that framework. Besides that, it just seems beautifully high-level to be able to express such a concept with a single statement "class DukeNukemEngine extends UnrealEngine"."I wince just thinking about the compile times that programs from such a language would take. Throw in a requirement for the language to be binary platform-independent, and who needs Microsoft to spur hardware upgrades?
Tim Sweeney identifies social inertia as the main cause of reluctance to adopt next-generation languages, but a concern with just as much importance in developers' minds is performance, like the development of Quake 1 shows. Until near-infinite processing power and/or bandwidth is accessible to consumers, it will continue to hold back advancement in such a manner. What else can I say? Tim Sweeney is a man ahead of the times.
Light a fire for a man and he'll be warm for a day. Light a man on fire and he'll be warm for the rest of his life.
Take a look at the GeForce - it does (3) and (4) just like those SGI workstations, and on a $200 (or $300 depending on things like RAM bandwidth) PC 3D card. No, it's not up to $100k SGI workstation standards, but it's getting closer. Nvidia's Quadro (which isn't much more than a souped-up Geforce) isn't a gamer's card, and SGI is working with Nvidia on future PC accelerators IIRC. Take a look at Anandtech's Quadro DDR review and see what you can get on a PC for under $1000.