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
All of what he talks about as "NextGeneration" was all stuff I learned 10 years ago when I first picked up OOP. Back then this stuff was old hat.
Indeed, time has proven that Framework-based approaches and Meta-Object-Programming are not a silver bullet eithr. They all have trade offs.
sigs are a waste of space
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
Shi a! Wo shuo henhaode hanyu.
:^) I have no idea how to say 'moral hazard' in Chinese. I've studied the language quite a lot, but don't get that much practice.
Actually, my Chinese sucks.
I have, however, faced similar enough problems in other langauges to feel confident in my answer. I invite you to look through the linguistics literature if you want a fluent Chinese speaker to pronounce on the issue. I'm sure there is one who has published on the topic.
Unless computers start doing more then the standard copy/compute/control operations (i.e. when we need to make quantum compilers) the choice of language doesn't make much difference.
The backward compatability he goes on about in length is nothing new, and can be done in any language, some of them just try to do it automaticly and hide it better then others.
The only factor that matters is "How fast can we spit out a profitable product with language X".
Choose your language accordingly.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
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
What you are saying is that the fact of importing a foreign term in you language is deja vu, oups, I meant already seen
BTW, I'm French and at first I was telling "already seen" instead if "deja vu" because I didn't knew how to say it, until somebody told me
"The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." Bill Gates,
I agree. The cost of hardware is miniscule compared to the cost of software maintenance. I mean, almost insiginificant.
My machine at work is about $2000. There is a full time person paid at about $40,000 year to support about 25 such machines, and that doesn't count lost productivity due to buggy software, reboots, etc.
I want a programming language that will let me write:
DoTheRightThing().
And I won't care how slow it is.
I found, if not the paper then what seems to be a good precis of it, and read it -- (all this and more) -- it's irrelevant to the subject discussed. I am in some difficulty as to why you thought it would be relevant. Proving that some concepts are cross-lingual impinges not at all on the question of whether all are, which lies at the heart of the "does language limit thought" debate.
I was 12 or 13 and writing in QuickBASIC (actually bought the compiler and actually sold 2 programs written in it.. paid for itself so I was happy) when I started playing ZZT. Thenn I printed out the programming manual. It was a whole new world. I had never heard of C++ or anything close to object-oriented technology but it all made sense. I truly loved ZZT.
There is one drawback and you might not want to hear this... ZZT has no throttling function... its basically impossible to run on anything much faster than a 486, everything runs too fast... sigh... I still play text-graphics based games almost daily (been playing Angband and variants for almost 10 years... i will beat one someday!) and ZZT would be a hoot to relive. If you or anyone else reading this knows of a program or some way that I can throttle my 350MHz machine to run this program in a decent manner, I would love to hear of it...
I wonder if Tim would still have/been able to release the ZZT source... ?
Esperandi
Would gladly pay for the ZZT source code and thinks its just fine if they wanna charge for it.
If you redefine cognitive science to include any scientific data about human minds, I'll agree that the only scientific inputs linguistics is getting come from CogSci. But by that definition, most linguists are cognitive scientists.
I could argue that the data coming from computer science, while helpful, isn't science at all.
The roots of linguistics aren't descriptive, they're even worse, there philological. Early linguists were interested in literature and historic language change. That's the one thing I have to give Chomsky credit for: establishing linguistics outside of the humanities.
Linguistics is no longer taught as an art at any respectable school of theoretical linguistics. There are still many universities where they teach what I might risably call applied linguistics but which mostly ought to be a part of the education department. That is a different story, but it also has different goals.
I spent two semesters in math classes and three in programming labs in order to get my linguistics degree. I spent hours doing SQL queries on usage databases in hopes of getting enough data to do serious statistical analysis to support my hypothesis.
More recently, it has become harder to be taken seriously as a young linguist without some knowledge of AI methods. (This doesn't apply to the hard-core Chomskyans, who don't believe in AI, as if that made any difference.)
In short, things are changing in linguistics.
As for having no feel for science, I have a Bachelor's in Nuclear Physics (from before doing linguistics) and let me point out that my citation of Berlin and Kay is not inappropriate. If the strongest form of Sapir-Whorf were true, this experiment should not have turned out that way. It covers more ground than the neurology of vision processing, since it shows that the mental manipulation of visual signals is independent of the native language of the subject.
We can reformulate Sapir-Whorf to get around this, but depending on who you read, we are left either with a hypothesis that can't be verified (and is thus not science) or a hypothesis so weak as to be useless.
Read Pinker on the subject, he puts forward his case against Sapir-Whorf on the basis (in part) of Berlin and Kay as a cognitive scientist.
Hey! Forth rules!
If I had to throw away all my nice dev tools and start over from popping in a byte at a time with 8 toggles and an enter key, the first thing I would do is code a Forth interpreter/compiler; even before I wrote an assembler (it's easier).
The only reason I don't use Forth now is because I've got the entire UNIX dev environment to support me, which is almost as efficient as Forth and gives you some hint of portability.
But Forth builds good programmers. You learn never to make a mistake, because mistakes eat your machine. You learn to debug your code by eyeball and brainpower, not with any machine aid. You learn to rewrite everything every time, and you learn that this can be faster than reading the docs for a library.
(BTW, none of this applies to ANS Forth, which is a bad joke from the people who made Ada; Forth is something you should rewrite for every machine you use it on, just ask Chuck)
Oh, you laugh now, but just you wait until we start writing massively parallel systems and you're begging Chuck to burn a thousand of his 250 MIPS (with a cheap fab) 10k transistor (with video processing!) processors on one chip.
Speak for yourself, buddy. My linguistics courses were plenty scientific. Perhaps you think that if we don't use numbers, it's not science.
And Berlin-Kay is in no way only about the purely physical process of converting signals from rods and cones in the eye into nerve signals, as you seem to say. If you've ever read their work and understood it, you'd know that. Or perhaps you think that there's nothing behind the eyes doing the processing that allows you to describe color?
Orwell's idea was mainly that with a simplified language you'd have a hard time discussing treasonous thoughts, which you could have.
Big brother was personified and anyone could want that image to be killed.
But, explaining that to enough other people to make it happen... That's where it's tough with a newspeak type language. And that was the idea. Keep conspirators alone, and thus unable to conspire.
...and many even be possible, but it's a very weak form.
Now, computer languages and human languages are very different matters. It is true that I pick my languages on the basis of what kind of project I have to do, unless the spec requires a specific language. When that happens, I can usually solve the problem, even if it isn't as much fun. If I can solve the problem in a language, I'm have some reason to doubt that the choice of language restricts project choices.
So, I'll retain my scepticism with regard to computer languages, but it's just scepticism, I may be wrong about the habits of programmers.
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.
However, "little languages" have a nasty habit of growing into full-fledged programming languages and the compromises that were fine when it was just a quick hack suddenly become ugly, cancerous warts.
IMHO, Tcl is an excellent example of a "little language" pushed too far. It was originally designed as a glue language for bits of C. The designer never envisiaged anyone writing fully-fledged programs purely in Tcl, and consequently there are some quite large warts lying around.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
Also, most will be hardcore gamers, which isn't always the same as hardcore geeks. These people are interested to hear that their hobbies are near the cutting edge of technology. And with the right development cycle, computer gaming has the capability of *always* being near the fore-front of the technological edge.
Because you all remember when running a phone-book type database was 'cutting edge' on D-Base III, right? `8r)
Disclaimer: I'm the Unix admin for GSI, running the chat portions.
--
Gonzo Granzeau
Gonzo Granzeau
"Nothing the god of biomechanics wouldn't let you into heaven for.." -Roy Batty
I had a look there, and the only paper to refer to Berlin-Kay gave a very rough overview of it. If you'd actually bothered to read the full paper (as some of us have), you'd know that it is about this very topic.
Keep your "opinions" to yourself, thank you very much, unless you have some facts to back them up.
No it isn't! BUT, since you're obviously not intested in genuine debate, I guess "hear endeth the argument". (but one last hint: there's a strong argument for calling all of philosophy since the Vienna School Linguistic Philosophy: but I guess now that you've cleared it all up they can all just go home/roll in their graves (pick an appropriate response).
That was true of the really old java run-time environments, but it hasn't been for a while now. All of the RTEs I know of compile the bytecode to native code before they execute it.
I know, a minor point.
-jacob
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
But, there are alternatives. One is that thought takes place in some kind of lingua mentalis that is the same for everybody and exists only in the mind. I think this is the majority position among linguists (but is by no means universal.)
There certainly is no evidence that people think in their native language at all, and considerable evidence agsinst the idea. The details would take some time to document and explain.
Due to the failure of experiment to show any Sapir-Whorf effect, after decades of trying, I feel secure in saying that the hypothesis is, certainly in its strongest form, as without merit as the aether or flogiston in physics.
As for books, I recommend starting with Pinker's Language Instinct. It contains some things that I don't think are true, but for someone who isn't a linguist these are mostly minor matters. Language Myths (edited by Bauer and Trudgill) is another good one, and The Great Eskimo Vocabulary Hoax by Pullum and McCawley.
Those are good places to start. If you're looking for something more like an entry level textbook, e-mail me.
Yes, I see where you're coming from, but I think the point you are addressing here is more "can new ideas ever develop?", which, if we accept the principle that language limits thought, is co-extensive with the question, "does language evolve/develop?". Well, clearly the answer to the latter question is, "yes". What I was thinking of, was more, whether translation from one language into another doesn't inevitably translate native concepts into different ideas, their nearest equivalents in the target language. See Heideigger for powerful arguments on why this might be the case.
Abstraction in a language doesn't have to incur slowness. I think you are thinking of "layers of abstraction." Such as "xml running on a regular expression parser running on perl running on java running in an applet running in netscape running on an internal scripting language running on C running on motif running on xlib running on pipes running on linux running on C over tcp running on ip running on ethernet running on linux running on C running on machine language running on a transmeta code morpher running on VLIW on Crusoe."
Well, I'm a member of a community that branched off from zzt, based on a zzt-like program called megazeux(which I'd link to if a good site existed). Anyway, one of my fellow members(kevin vance, who I thnk goes by kvance here)is currently working on a gl reimplementation of zzt, and it's really weird :P http://www.linuxstart.com/~kvance/evil.j pg and http://www.linuxstart.com/~kvance/evil2 .jpg show some intruiging screenshots. Anyway, this looks like it may be the thing for you, and there is a port of megazeux for linux coming(eventually) in the future. Hope this whets your zzt in linux appetite. Also, zzt.org is a good source of zzt information if anybody cares.
Completely wrong. Try to catch up on some 20th Century philosophy in your free time.
I'm familiar with Lakoff's work on metaphors, but I don't think his work touches on the Sapir-Whorf question. To put it simply, I don't think his work in metaphors qualifies as linguistics.
Now, I think what he is doing is useful and I'm all for it. I like Lakoff, and his work on categorisation (which is a linguistic topic) was a major influence on me before I traded career for money and became a programmer. However, are his metaphors really linguistic, or rather cultural commodities? None of the metaphors I know him to have described involve word play (eg confusing 'free as in free beer' vs 'free as in freedom'). If I recall what Lakoff was saying, there is no fundamental reason, other than chance and culture, why those same metaphors couldn't exist in Chinese, or Inuit for that matter.
Common sense can throw you for a loop. Look at quantum mechanics - it's about as counterintuitive as you can get. Always hold out for empiricism.
The days of philosophy's monopoly over the mind are long past, and philosophy is better because of it.
and
I use windows. Sorry.
are somehow related.
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.
The main implication that occurs to me is that verbs aren't conjugated, and you probably need helper verbs for different tenses (or are expected to just pick it up from context)
Daniel
Hurry up and jump on the individualist bandwagon!
If there is a concept which is unexpressible in another language, I would like to see it.
Expressibility is not strong enough. You can express quantum chromodynamics in English, but you sure as shit can't use English to solve problems in quantum chromodynamics.
1) Java does make programming easier than C++. It eliminates the need to screw around with stupid #include guards, forward declarations, memory allocation policy, and Java exceptions instantly zero you in on the line of code causing problems, which makes debugging way easier. Java also comes with *WAY* better runtime libraries than ANSI C++.
2) It's not significantly slower. You made the assertion, you provide the benchmarks with source. I'll optimize your Java benchmark to show you that you don't know what you're talking about.
3) You don't have a clue as to what you're talking about. Almost all complex games use a runtime interpreted scripting language that is significantly slower than Java in execution speed.
QuakeC (Quake1), UnrealScript, Tribes Script, Half-Life, etc.
The reason why this might confuse you, is because you don't understand the optimization principle: 90% of of the CPU is spent in 10% of the code. Switching from interpreted scripts to binary C might yield a 10% framerate increase, big deal.
On the other hand, with interpreted scripts, you're guaranteed not to be hit by a VIRUS in that free quake module you just downloaded.
VMs also make it easier for game developers to dynamically test game logic without having to rebuild/relink a library and reboot the Quake server.
One thing's for sure, Carmack knows alot more than you. And he has a Ferrari.
Object oriented programming *works*. Even the Gnomies who rag on KDE because C++ use OO-like constructs in their "pure" C code and brag about their Python wrapper.
... to express a class of GUI widgets".
But you yourself use OO. Just look at your post. You write "mini-languages
A Government Is a Body of People, Usually Notably Ungoverned
"Why did you not write a separate mini-language for each of the GUI widgets?"
What kind of idiot would write a language he is only going to make one statement in? I am not against solving the problems that OOP is meant to solve, it is the methods that do not work.
When I write a mini-language, it is to parse many simple and concise descriptions of a group of similar things. A group of similar things can be described as a class.
In an OOP language, there is a formal way of expressing things that fit into a class (in the general sense; the formal OO and C++ terms "class" have different meanings from each other and from this general English one). This formal method is often excessively verbose, inadequately expressive, inefficient, and generally a pain in the ass.
So the reason I don't really like the majority of the elaborations on C syntax in C++ is that they are trying to create a single comprehensive method of expressing the infinite possibilities of variations on a theme. Learning this method takes too much effort (hence the oft repeated complaint "nobody knows all of C++"), using it takes too much overhead (both in programmer effort and in inefficiency of the final product), and it doesn't even make a good fit half the time.
Don't pay any attention to the actual comment I posted, wilya now? Too difficult, I guess. Like I say, if you want to argue, I'm here (although delayed a few days sometimes); if you don't, then... what can I say? Sorry if I've misunderstood you, but you don't seem to want to argue; you merely restate you case in increasingly-incoherent terms.
Paul's right; the Berlin and Kay paper is about human vision processing and not about the manipulation of abstract conceptual structures. The two could hardly be farther apart. But this is the problem with linguistics in general - it's roots are in a descriptive field much like botany or zoology. These two became modern "hard" sciences only with the advent of biophysics, genetics and molecular biology.
Linguistics is still waiting to cross that threshhold. Its only truly scientific inputs are from computer science and cognitive science, and both of these are still relatively new. Linguistics is still taught more like an arts subject like anything else, a bit like psychology used to be.
This affects both the type of students attracted to the field, and their subsequent education. As a result, the majority of linguistics students have a relatively poor understanding of (and no instinctive feel for) science as a result. Your inappropriate citation of the Berlin and Kay study is a good example of this.
Consciousness is not what it thinks it is
Thought exists only as an abstraction
I totally agree with what you meant, and the guy you were responding to should note what you said.
That said, I feel compelled to point out that "free as in speech" is still ambiguous in conveying the sofware concepts: "open" source, and GPL-user vs BSD-vendor freedoms of redistribution. It's easy to conceive of paid source you can't redistribute, free object you can, and source you are free to redistribute as object, and object whose source you are entitled to see.
Corrinne:
:-)
Well, you just answered my unspoken question of "Man, I wonder how much of a pain in the ass is it when after twenty something years of learning you're still asked questions about some thing that you've had since before you were born."
Now I know
QOTD: "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"?
A couple (real) questions sprung to mind, incidentally:
compiler internally generating and maintaining a virtual table of a lot of NULLs
Could you elaborate a bit more on why architectures involving derived classes create wasteful indexes of information? I'm unfamiliar with compiler design, and am curious where this generation comes from.
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.
Basically, an object in such a class is constrained by the "contractual expectations" embedded within the parent class. There are certain properties/functions which the class is expected to support, and failure will ensue if such functionality is not implemented.
But does this burden disappear at all when the coder must explicitly know to provide a predefined degree of functionality? Doesn't having a base class enforce a minimum degree of functionality on derived classes, thus preventing situations where the programmer forgets to add some property and chaos ensues?
It is more difficult to document and comprehend such a deep weaving web.
So what can be done to make deep weaving webs more understandable? I did some experimentation with the autodocumentation system Genitor a while back, but what have you seen, either implemented or theoretical, that would make deep webs feasable for human comprehension?
That, of course, leads into a more disturbing concept: Could the human ability to comprehend complex logical relationships be considered a bottleneck that needs to be progressively abstracted as time goes on? Could this pose serious problems for software and hardware design as time progresses? Does it already?
Just interested in what you think.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Anyway, My wishlist for next popular language:
- Layered architecture
- Functional core
- Component hype
- Lambda calculus made easy
- Hindley-Milner type system
- Proper tutorial on abstractions and complexity
- Concurrency
- Only dependencies restrict execution order
- Top-Down + Bottom-up process
- Binary compability
- User friendly(tm) open-source GUI library
--1) The ostrich algorithm, 2) Detection, 3) Prevention, 4) Avoidance
He argues faster machines should not be required, yet he years for more and more abstraction.
Actually, abstraction eventually traslates into faster code. Who would want to work out all the optimisations gcc dose in ams? It would take you a lot of work just to figure out what gcc dose in 1 second.
Simillarly, functional langauges will eventually allow the compiler to generate code which takes advantage of opimizations which a human could not reasonably do. Example: some experements with structured self-modifing code (i.e. functions which write optimized functions) have achived massive improvments in preformance (factor of 10 for Henery Masslin's Sethisis microkernel; this can be done by object oriented lanagues too).
Currently, it is easier to speed up the hardware, but when we start hitting the theoretical limits we will need to switch to compiler optimisations for speed improvment.. and imperitive langauges are considered to be something of a dead end for optimisation.
Jeff
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
Debugging this stuff is hell. You can't watch the expansion process at compile time, and most debuggers don't provide much help stepping through the output of something like this.
LISP started to develop cruft like this just before it tanked. (Anybody remember the MIT Loop Macro?) It's an indication that something is terribly wrong with the language and nobody knows how to stop it.
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.
If you redefine cognitive science to include any scientific data about human minds, I'll agree that the only scientific inputs linguistics is getting come from CogSci. But by that definition, most linguists are cognitive scientists.
;o)
I'd have to disagree there. Cognitive Science is a fairly well-defined (if multidisciplinary) field and it relies heavily on neuroanatomical studies. I contend that in CogSci, a psychological theory (including anything in Linguistics) without neuroanatomical evidence to support it, is just pure speculation.
I could argue that the data coming from computer science, while helpful, isn't science at all.
It'd be a weak argument. Computer science really is a science, in the sense that it is a study of the behaviour of real systems - both physical ones and abstract ones. It allows us to put the math into motion, so to speak. It comprises both theory and practical experimentation; results can be numerically quantified, predicted by theory and verified by experiment. There is no meaningful definition of "science" I know of, which doesn't include Computer Science. Maybe you're still thinking more in terms of the old notion of "Natural Philosophy".
More recently, it has become harder to be taken seriously as a young linguist without some knowledge of AI methods. (This doesn't apply to the hard-core Chomskyans, who don't believe in AI, as if that made any difference.)
That's truly excellent news. About time! I believe Chomsky is vastly overrated. It's probably because he had the whole field of theoretical linguistics mostly to himself for so long.
...[mini-resume]...
The science credentials you claim are certainly more than adequate. I'm glad to see that science is creeping into the curriculum in some places at least. Perhaps you're talking about Linguistics as currently taught in the US? Not that it should make much difference - but my most direct experience of the field comes from my sister who's now doing her Master's at the University of York in the UK. From what she tells me, the field is still mainly about descriptive theories which provide very little in the way of testable predictions. That, in my book, is not science.
my citation of Berlin and Kay is not inappropriate. If the strongest form of Sapir-Whorf were true, this experiment should not have turned out that way. It covers more ground than the neurology of vision processing, since it shows that the mental manipulation of visual signals is independent of the native language of the subject.
I won't argue with that; vision is much older than language and all the neurology involved is highly specialised and mostly physically remote and separate from the associative cortex and other structures (Broca's, Wernicke's) involved in language processing and abstract reasoning. I agree that language doesn't shape vision at least on a low level. It is silly to advance a theory that *every* single aspect of our experience is constrained by language. Nothing is ever so simple or clear cut in complex emergent systems like human minds. But even a misconstrued "Strong" Whorf hypothesis doesn't claim any such thing. And I don't believe anyone here is supporting the strong form (I might like to, but I wouldn't dare
I said your citation was inappropriate because I believed you were advancing it in support of the idea that language does not even partially constrain abstract thought. I hold that reports about the experience of simple visual stimuli are too limited in scope to have much to say on that subject. In any case, Berlin and Kay's conclusions in Basic Color Terms have been effectively disputed (and I for one fail to see how their results are supposed to *disprove* the dependence of subtle colour perception upon language), and Sapir and Whorf have been unjustly denounced most likely for sociopolitical reasons. It's just not done, these days, to suggest that culture or ethnicity could possibly have any deterministic effect on behaviour. Bah.
Still, thanks for the flame-free argument. I always enjoy debate when it's conducted on a civilised level. Kudos to you for that.
Consciousness is not what it thinks it is
Thought exists only as an abstraction
Sorry, but you're wrong.
Philosophy is a study of the non-technical, that which can't be measured. The idea of philosophy is to examine what the limits of knowledge are, not the specific knowledge.
If you can test something, it's no longer philosophy.
If you can devise a test to see if people can't conceptualize an idea without a word for it, then it becomes a testable theory.
I myself think the theory is bunk. A society might not have 'war' in their vocabulary, but they'd understand how something bigger can move something smaller, perhaps hurting the smaller thing in the process. This can easily be extrapolated up to war. They may not understand why you'd go to war, but understanding of the basic concept wouldn't escape them.
If 20th century philosophers have moved into the realms of the testable, then they're not philosophizing.
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
If color, which is obviously expressed differently across langauges, does not affect perception of color or mental processing of colours in the abstract, tell me what test will show that a concept can't be manipulated, or whose processing is in some way affected, by a person's langauge.
Having worked with the people responsible for making phone books in Inuktitut, and Bible translators for languages that don't even have a word for 'cross', I submit that the relative ease with which ideas and documents are translated and communicated across language groups is pretty damning evidence agsinst that idea.
Can you find a contrary case?
The for loop is explicitly sequential. The notation is not. If dealing with operations with potential side-effects this notation actually contains a promise that you don't have to worry about side-effects - which allows the compiler to generate more parallel code. This in turn can be optimized to be done with vector operations, or (in a different problem domain) across chips.
In other words the for loop is a barrier to optimization since in order to observe certain classes of optimizations the compiler has to figure out your code (and verify - for instance - whether the value of i has to wind up being calculated.)
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
I think what some people here are grasping for is the correlation between lack of word for an abstract concept in a language and ignorance to that abstract concept. Coining a word allows for efficiency in calling up meaning. However, to actually understand the word, you must understand the concept.
Orwell describes a people who are brought up into ignorance leading to a particular mindset. Their coining of new terms to efficiently describe the abstract concepts they came into contact with is only a result of understanding that concept. Ignorance, not language, was what held them back.
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"?
From one of the INTERCAL enthusiasts' webpages:
So, you think you've seen it all, eh?
OK. You've coded in C. You've hacked in LISP. Fortran and BASIC hold no terrors for you. You write Emacs modes for fun. You eat assemblers for breakfast. You're fluent in half a dozen languages nobody but a handful of übergeeks have ever heard of. You grok TECO. Possibly you even know COBOL.
Maybe you're ready for the ultimate challenge...INTERCAL.
INTERCAL. The language designed to be Turing-complete but as fundamentally unlike any existing language as possible. Expressions that look like line noise. Control constracts that will make you gasp, make you laugh, and possibly make you hurl. Data structures? We don't need no steenking data structures!
INTERCAL. Designed very early one May morning in 1972 by by two hackers who are still trying to live it down. Initially implemented on an IBM 360 running batch SPITBOL. Described by a manual that circulated for years after the short life of the first implementation, reducing strong men to tears (of laughter). Revived in 1990 by the C-INTERCAL compiler, and now the center of an international community of technomasochists.
This is an excerpt of a program that does ROT-13, written in INTERCAL. Being a non-INTERCAL developer, I chose what seemed to be a representative sample of the code.
(1) DO
DO
DO
DO
DO (11) NEXT
DO (2) NEXT
DO (12) NEXT
(11) DO (13) NEXT
PLEASE FORGET #1
DO (12) NEXT
(13) DO (14) NEXT
PLEASE FORGET #2
DO (12) NEXT
(14) DO STASH
DO
DO (1000) NEXT
DO
DO
And so on.
Yeah, I can see how writing Space Invaders or Quake bots or a MUD would be MUCH better in this language.
[
Abstraction can slow things down, but it can also speed things up.
Not everyone here is an asm guru. I know enough that I could easily write a memset routine for x86 and a few other platforms, but I can't guarantee that it'll be as fast as the library code.
Ditto with, for example, complex numbers. I can (in c++) declare n, i and j as complex numbers, set them, and say n = i * j. I could do the same with structures holding the real and imaginary, or parallel arrays. And theoretically, I could do it faster, if I coded it in ASM. But, the abstract level lets a programmer who majored in math do the actual code, probably squeezing out a few extra cycles by knowing shortcuts, and guarding against any special cases (div by zero type things) that I may not know about.
Abstraction also lets the compiler use the computer to its fullest. I could code vector manipulation, for a 3d engine, in asm, and even if it was provably the fastest code, that wouldn't do me any good with a new cpu. If I write it in C, or better, something more abstract where I can hand off whole matrices, the compiler will (ideally) know the the target CPU has Altivec, or 3dnow, or perhaps some higher-level FPU capable of whole matrix ops. By writing code that attains some reasonable fraction of the best speed, say 90% or so, you write code that attains that speed on all architectures, and uses new features with only a recompile. Hand code the routine in ASM and you only gain 10% or so, which might be important in a critical loop, but you lock yourself into having to recode it later, to get the same speed. And that means having to be an expert on all the target architectures.
And then, there's the argument that you can always give away abstraction, writing some critical code in ASM, if needed. You can't go the other way and use inheritance in ASM (or in typical assemblers.)
Languages that restrict you, that prevent you from being specific when you know something the compiler doesn't, are bad. That's why nobody uses Pascal. But the ideal language lets you ignore all the finicky details until you decide otherwise, it doesn't require anything either way.
"If you can devise a test to see if people can't conceptualize an idea without a word for it, then it becomes a testable theory."
Have you, or has anyone else, devised such a generic test? If not, then you are rather hoist on your own petard, are you not?
I don't think you quite get it. Take a look at what Objective-C does, and take a look at Common Lisp The Language, and read the section on CLOS in the appendicies.
Objective-C's ability to delegate procedures to other classes achieves a lot of the "virtual classes" concept. You can also selectively override parts of a class as he describes in virtual classes in objective-c.
The Common Lisp Object System (CLOS) and it's MetaObject Protocol (MOP) allow you to do what's described with a virtual class, and more (so much more that it's a bit intimidating to think about it).
CLOS implements object heirarchies as a list, and instead of only thinking of procedures that can be applied based on type, it has a set of rules that determines which procedure in a list (think an array of function pointers) will be applied in a given situation based on a set of rules. Sounds like C++ or Java.
The MOP, however, lets you define that behavior - you can specify that the object system will change it's behavior when you need it to.
So, it's been done and proven, but it's still "academic" from his point of view (ignoring the implementation of next/openstep, and the fact that LISP machines did do a lot of work at one point, and lisp still does stuff... it's just not mainstream. Too bad...)
-Peter
== Just my opinion(s)
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
Of course, in his portrayal of C as being an ancient, out of date language, he goes so far as to claim:
Apparently Microsoft Windows and Mac OS weren't "mainstream" enough for Tim. (I won't argue that they're kludgy... that's a whole different problem.)Skipping over brief discussions of hardwiring games and assembly, we come to C. He discusses slow adoptation of C by game programmers, then holds DOOM as a turning point of some sort:
While DOOM didn't rely on assembly to run, it relied on assembly to run at acceptable speeds on mainstream computers. In addition, usage of C and C's contemporaries was already well entrenched in the game industry by that point.I'll gloss the section on C++. I think he's getting overworked about the failings of C++. Many, many projects continue to work in C++ just fine without collapsing. I think he's a bit arrogant for lump UnrealScript into the mix. He filtered out Pascal and other C contemporaries to presumably keep his list simple, then lumps in a fairly specialized pet language.
Getting the future we get to the good parts. He wants to discuss "parametric polymorphism." He handwaves away C++'s templates with:
Again, he ignores the many people who find that templates (especially the STL) provides many of the features he wants without introducing the ambiguity he does (more in a moment). He also ignores the C programmers who have been programming in object oriented styles for years. Oh well.Anyway, we get to his list of things he wants for "'parametric polymorphism' in its full glory." (His extra quotes, not mine. Read into what you will.) First we wants an "open world evolution of source code and binaries." I read this as, he wants to be able to change various bits (containers, algorithms, other bits) without breaking compatibility. Why templates fail as a "link-time feature" is beyond me. I manage to "evolve" my template containers and algorithms without breaking anything just fine. Sure, I can break things, but I fail to see how any language can stop me from breaking things.
He wants "functions references bound to specific objects." I can't figure this one out. I certainly can stick function pointers in objects. Perhaps he means closure, which is easily done with function objects (an object which looks and acts suspiciously like a function). (This is slightly inelegant in C++, but certainly not an "enormous amount of 'duct tape'".
He also wants his polymorphic types to support bounds and constraints (simple enough), and "higher-order function calling" (No guess).
He then dwells on an example. He's got three integer arrays A, B, and C. He wants to add the each element in B and C and place the result in the corresponding element in A. He seems deeply bothered that C++ doesn't look at "A = B + C" and "do the right thing." He seems to ignore other, reasonable interpretations of B + C. Perhaps it means concatenate the arrays, or add all of the elements in B and C into a single number and put it into A[0]?
Looking at things this way, Tim Sweeney naively assumes that everyone can agree what + means in the situation.Ultimately he appears to be looking for a general way to work on sets in this sort of way. It's a darn shame he hasn't looked at the STL recently, since tools like for_each() provide a solid, general basis for running over a single array, and a for_each like function running over two containers isn't very hard to write.
Moving on, we find:
Why this isn't possible (and already being worked on just fine) in C++ (or even, god forbid, C), is beyond me.His discussion on virtual classes and frameworks is interesting. Somehow I'm not feeling a compelling calling for virtual classes, but it's interesting.
His discussion on how wonderful UnrealScript is particularly interesting. He wants the various "good bits" of Java (binary interoperability, security), plus a few more (language supported serialization that automatically is backward compatible). This sounds nice and all, but he quietly ignores speed issues. Given that Unreal shipped with framerates regularly below 10fps on systems that were "up to date" when it shipped, I suspect he doesn't care. Like the Java advocates say, "A slight speed hit is okay, since computers keep getting faster." Of course, the "slight" speed hit generally turns out to be at least cutting your speed in half, it isn't okay. I'd certainly notice Word getting 50% slower, and I darn well want to run by games with as many graphical bells and whistles on as possible. Oh well.
Search 2010 Gen Con events
Abuse (a great game) was written almost entirely in Lisp. I can't think of other examples, but there's no reason there couldn't be more games written in Lisp.
Be careful, even the author of that game readily admits that it's not "almost entirely" written in Lisp. A custom Lisp is used as the scripting language, but there's a whole lot more C code than Lisp code in the game. It's something like 85% C and 15% Lisp.
Java has its own performance based problems for performance critical sections of my code.
Are there versions of Java or implementations of Java in which only user explicitly specific garbage collection?
A Java machine arbitrarily deciding when and how to garbage collect when I want to maintain network connection or something like this does not appear helpful.
Garbage collection-less Java would of course not have this problem for me.
I actually agree with the gist of your post (as I interpret it), that is, that the realm of philosophy is those areas that haven't proven amenable to scientific investigation. Ironically, some philosophers would consider the very idea non-sensical -- oh well, there's nowt stranger than folk! My main point is, I don't concede that such a general proposition as "there can never be a proposition in language A that is not fully-translatable into language B" a statement ammenable to scientific proof. I find my empirical experience, plus the arguments of such philosopers as Heideigger, rather argues the opposite. Perhaps it is easy for those who belong to the dominant language/ideology combine on Earth right now to accede to the theory that language and thought are a one-to-one transformation. Speaking as an Irishman, my history seems to prove the opposite.
Copyleft stops me from running off as many as I like?
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
This is an extremely anti-modular misfeature, which is being phased out of the language, but which is still a thorn in the foot of any large system.
Absolutely agree--I have had to work with large systems in Perl that use dynamic scope intensively, and it's horrible.
You seem to be implying, though, that this is a reason not to start a big project in Perl today. I disagree. If your coding standards (for large projects you do have coding standards, I hope) mandate use strict and discourage use vars (in other words use my variables for everything), it's no worse than C or C++, and has an object system that I rather like.
-Doug
The 'problem' is that english is too slippery, and is defined by usage. 'Free' means, liberty, and also, unpriced. That's because we've collectively added to it over time. It means both, depending on context. It's not that english doesn't have a word for 'free as in speech' but that it doesn't have a word exclusively for it.
German doesn't have a short root word for a lot of things, it has compound words that are like our phrases. To complain that english doesn't have a short work for every concept is like complaining that german has long words.
If 'free as in speech' is what you mean to say, then say it. Or say 'legally unencumbered', or 'unrestricted copying', etc. Find a phrase that explains exactly what you're trying to say.
I'd hazard a guess that 'libre' in french doesn't mean 'free as in speech, under USA law'. It probably means 'allowed to exercise it's rights' or something similar, which would lead a purist to ask what rights software has. More correct would be 'available for use in exercising your rights' which illustrates that the software is available for you to use in any way to exercise any of your rights, but which is still a bit vague in defining what rights you think people have.
(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.
Perhaps you think that if we don't use numbers, it's not science.
I can't think offhand of any cases where this wouldn't be at least partly true. Science is about hypothesis, experiment and measurement.
perhaps you think that there's nothing behind the eyes doing the processing that allows you to describe color
No! You miss my point. An assertion about the role of language in the reporting of direct visual experiences says nothing about its role in abstract reasoning. Which is where the real controversy lies. Does our language guide and inform our mental habits - I think it does.
If science is infiltrating the linguistics field in some institutions now, I'm glad to hear it.
Consciousness is not what it thinks it is
Thought exists only as an abstraction
Why did you not write a separate mini-language for each of the GUI widgets? Don't answer, I'll guess instead. It's because those widgets have a lot of properties in common so using a single interface to them made sense. Now this isn't an accurate definition of OO, but it's the basic kernel of the OO idea.
I will agree with you that enforced OO is a pain in the ass, particularly when you aren't working with objects (I really hate those books that tell you to "find" your objects in the problem before you start coding). However, your post was dissing all of OO, and C++ in particular, for no apparent reason other than its age or the fact that you didn't write it.
The advantages of OO programming do not require a OO language. In fact, most modern programmers probably use them on a day to day basis, just as they similarly use structured and functional concepts.
Abstraction => integer, widget, file
Encapsulation => source file, module
Derivation => a button is a widget
Polymorphism => I sort numbers and words the same way.
A Government Is a Body of People, Usually Notably Ungoverned
Oh, zzt.org is pretty cool too. PlanetQuake meets ZZT. I like. :) (How long do you think it'll take for some PlanetQuake junkie to "discover" ZZT like when Scorched Earth suddenly became the ultra-trendy Quake scene kr4d-31337 g4m3 0f th3 m0nth? :)
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
- First and most important of all, it has a good mechanism for exposing C functions to scripts. This is crucial.
- You can strip out just about EVERYTHING, even text functions if you want. Great if you have to target a PSX or N64.
- Similarly, you can save memory since you're able to compile script text, then throw the text away and keep the bytecodes.
- A flexible syntax that could be used like C or as a line-based language, in scripts, on a command line, or in a config file.
- Garbage collection and a fixed heap size.
- Debugging support, which is often forgotten but important.
However, the script <--> C++ interface, though simple and mostly effective, was still fairly primitive and certainly not on the level of UnrealScript (which BTW just totally rocks the party, I hope we can see more of it soon). I would really like to see more scripting languages which bind as tightly with a C++ framework like UnrealScript does, for instance parsing C++ header files instead of depending on an interface to be defined elsewhere. I think just about every program should take advantage of a glue language, and the better the interface, the better the gluing. =^)I also checked out ICI (cool), saw whether Perl could be cut down to size (not easily, but it would be worthwhile), TinyScheme (sure is!), and Small (very cool!). Now that there's more attention to large-scale, reusable game scripting (take a look at a new project, GODL) I think we should expect that good games will have a good scripting language behind them.
With human languages the semantics and primitive data types turn out to be the same. We can see it across the specturm of linguistic categories, particularly if we look at special cases: rhyming, alliteration, stuttering, aphasia (e.g. forgetting the words for different emotions), synonym, homophone, babytalk, ... all of these things exist the same regardless of language. When you look closely, the apparent differences are simply syntactic.
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.
The TUNES review basically says "the standard sucks because it doesn't standardize half the things that are really necessary." Yep. However, that doesn't mean that there aren't Scheme implementations that do a good job of filling in the gaps. In particular, Rice University's PLT group puts out a Scheme environment, DrScheme, that has everything that TUNES complains about and more (including a good object system). DrScheme is on the short list of Scheme environments to be using. True, it's not standard, and that's a problem. However, it's fairly well-documented (with a graphical help browser, no less, that doubles as a minimal HTML renderer), and it's supported by some of the most prominent Schemers around (in fact, members of the PLT run schemers.org, what TUNES calls the "number one page about Scheme"). They're accessable, too- if you think it can't do something you want to do, post to comp.lang.scheme and one of the maintainers will tell you that you're wrong with a degree of politeness proportional that in your original message =).
Of course, I go to Rice, and I know the people who maintain DrScheme, so I'm biased. However, having programmed in it for two years, I can tell you that if you can't do something in DrScheme, that's because you shouldn't be allowed to do it at all.
-jacob
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
Gulp, Sploosh.....
I love this! I think the linux community should embrace programming language reform, for we are smarter than Visual C++, and we are smarter than the marketing giants who have been pushing it (and Java, etc.) down our throats.
/ fox/mosaic/people/petel/papers/pcc/pcc.htm l
;)
This article is obviously the product of a good hacker who's just discovered the miracles of advanced programming languages. I think he gets carried away on the ideas of document/view (sounds like MFC to me, ugh), but his heart is in the right direction!
By the way, Standard ML has been doing "parametric polymorphism" (or parametric types) right for almost 30 years. Not to mention higher order functions and safe static typing. ML 2000 will add subtypig and objects to this. (Just a personal favorite, but ML might be a good starting point for someone interested in advanced languages).
Other comments:
In my opinion, bounds should NOT be part of the type system, but should be inferred by the compiler as optimizations (to remove dynamic checks where possible). It is very difficult for the programmer to do these kinds of analyses. (Imagine a notzero type of integer, and division is function type (int * notzero) -> int!) On the other hand, experience has shown that array bounds checks are one of the biggest cycle-wasters in modern languages, so this issue must certainly be addressed somewhere.
I've mentioned this before, but certain advanced languages also allow proofs of their safety to be generated and then checked by the client (PCC = proof carrying code). This allows for bare-metal code to be downloaded and executed without any security concerns (the user need only trust a proof-checker which is very simple [about 60 lines of C]), rather than a whole sandboxing system and interpreter (Java). Check out
http://foxnet.cs.cmu.edu/afs/cs.cmu.edu/project
Yes, I am a Programming Language snob.
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.
Thanks, that's funny! Have you ever heard of Yogi Berra, an American baseball player? He's famous for saying things like: "It's deja vu all over again!" Deja vu encore! Perhaps there's a funnier way to translate it?
Yes, we have those concepts. You are unfortunately arguing against yourself. You didn't say "we have those words", because they are just words. You said "concepts" as in ideas and thoughts: you can understand these ideas in the face of imprecise words, and Africans and Native Americans can understand those concepts also with different words.
I'd like to see you walk up to their village and attempt to describe ownership to them.
But according to your argument, language influences thought. So, all we'd need to do is teach them the words, right? That should be easy... but it's wrong.
Grass and green... blue and sky... Instead of 'chief' you have 'one-who-does-good' - think about how different that is from the perception of government as a hierarchy.
Yes, but we have orange oranges. And yellow cowards. Do you think you are influenced by those word/colors? I don't think Native Americans are either. We also have New York... think how different it is from old York, which did not pop into your head till I mentioned it. Words, language... they've nothing to do with thoughts but rather with communication.
By the way, this is all taught in linguistics classes, it's standard science, shoulders of giants, etc. By the way, it just occurred to me that I'm a native American, but I'm just not a Native American. When spoken aloud (the true definition of language anyway, but that's another whole can of worms) you can't tell the difference: the language is not the idea.
As a SlashDot discussion grows longer, the probability that it will become a discussion of the Gnu Public License or the US Constitution approaches one.
: Fruitbat :
I have discovered a truly remarkable
Hi, I really tried to understand Tim's example of virtual classes with model/view and spreadsheets, unfortunately I didn't get it:
This seems like a good design, but it doesn't work well: all the functions in SpreadsheetModel have types indicating they work with an arbitrary View subclass, and vice-versa.
Could someone please explain to me what he means? If the types are not specific enough, maybe the whole design is wrong?! I'd be grateful for an answer...
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...
FORTRAN was old when I wrote my first computer programs, many years ago. Even though its popularity has waned, I still know programmers and scientists who write everything in FORTRAN.
I'm sure that some new language will eventually replace C and C++. That day is likely to be decades away. People forget how long it took for C to become a popular programming language. See Dennis Ritchie's paper on the history of C.
As a side rant, whatever happened to languages that could be completely described in a thin book such as Niklaus Wirth's "Pascal - User Manual and Report" and Kernighan and Ritchie's "The C Programming Language". Too many languages and operating systems have become unmanageable waste dumps of "features".
Mea navis aericumbens anguillis abundat
I think you overestimate the involvement of conscious mental activity in colour classification. Colour perception is really a preconscious phenomenon.
It has been known since Young and Helmholtz in the 19th century that the division of the spectrum into perceived bands of colour is completely determined by genetically determined neural wiring and retinal pigments. And lower animals endowed with colour vision are able to classify colour stimuli - without any equipment for language or abstract reasoning. Bees have colour vision extending into the ultraviolet. But most scientists wouldn't contend that bees must think about what they see in order to recognise flower petals.
In the Berlin-Kay experiment the subjects placed their marks on the diagram according to eg. their perception of "red" and "blue". It's hardly possible to consciously analyze such a basic perceptual experience. It can only be done on "feel". In that limited sense we hardly differ from the bees.
Consciousness is not what it thinks it is
Thought exists only as an abstraction
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?
If there is a concept which is unexpressible in another language, I would like to see it. Some things are not convienient or easy to translate, some can only be accurately conveyed with some longer explanation, but if an idea is unthinkable in another language - if in any way language (not culture) affects perception - this difference should be measurable.
That makes it no longer philosophy. When the hypothesis has measurable effects, it's science.
Berlin and Kay tried to resolve this problem in the 60's, using colour terms to see if people's perceptions of colour depended on major categories of colour in their language, and came to exactly the opposite conclusion.
I hope you're not suggesting that we all share a common language structure genetically preconfigured in our brains.
I admit that there will be practical limits to the complexity of utterances, in terms of the number of nested clauses etc., because of the (largely) shared limitations of our brains. But apart from that, grammar evolves within a culture simply according to need.
If a language is to be complete, some elements *need* to exist - nouns, verbs - just as procedural computer languages must have variables and executable instructions representing sequence and selection between conditions to be useful. And since the physical world is made of objects existing in time and space, acting and being acted upon, it is necessary for grammars to share constructs expressing relative proximity, tense, and who did what to whom. Necessity is the mother of invention, as Plato says. Or, to paraphrase Voltaire - if grammar did not exist it would be necessary to invent it.
But I see no solid evidence that any specific grammar or metagrammar beyond that is genetically preconfigured in our brains. If you think you have such evidence, then please share it.
Chomsky never succeedes in providing such evidence. And in the last few months, the most outspoken critic of Chomsky has become Chomsky himself; he's finally abandoned the burgeoning edifice of complexity he's been promoting for the last 50 years and now favours a "minimalist" grammar.
Ha! Vindicated at last...
Consciousness is not what it thinks it is
Thought exists only as an abstraction
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.
I see no contradiction here.
If you ask someone to classify a colour, there is very little abstract reasoning taking place! In any case, the reporting of which I speak was really non-verbal - the subjects in the Berlin-Kay "Basic Color Terms" experiment only had to put a dot in the middle of each perceived colour region and draw around its boundaries. Neither speaking, nor verbal nor abstract reasoning, was necessary. Are we talking about the same experiment or not?
Consciousness is not what it thinks it is
Thought exists only as an abstraction
Oh: "Language of the Future"? This kind of typechecking dates back to the late 1970's.
(Btw. does anyone else see "functional" above? Some problem with SlashDot's breaking of long URL's?)
The one "nit to pick" with Tim Sweeney's article about programming languages is that his parallel to "linguistics" refers exactly to this kind of claim, citing it as a "well known fact in linguistics", while among the cognitive linguistic community, it is considered more like a "well known misconception".
If you wanna look at the source of a good JVM you can always look at Sun's if you don't mind agreeing to SCSL. If you'd rather not be chained, then I'd suggest grabbing the VM from Transvirtual. It's not perfect, but it's not bad.
Other good VM's for other languages: Squeak and CMU Lisp (not really a VM in some ways). E-mail me if you want pointers.
sigs are a waste of space
and no, I don't have a personal opinion on it, eiher way. Goverment&Binding (aka Principles&Params in its later versions) came forward enough to predict non-trivial language features that could be checked; I don't think minimalism has gone this far yet.
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.
I think Tim Sweeney is not being entirely genuine and even-handed in his treatment of what has gone before and what needs to be newly invented. Early on he mentions functional languages, naming LISP, Haskell and Miranda explicitly, but without any useful examination he dismisses them as irrelevant ("theory", instead of "practice"). Yet then, in the remainder of his essay, he effectively makes a very sound case for bringing in precisely those high-powered features that make functional languages as powerful as they indeed are.
LISP users have been doing all the clever things he mentions not just for years but for *decades*. To a significant extent, more modern functional languages (LISP is partly functional, partly imperative, and partly various other flavours) effectively just put syntactic sugar around LISP concepts to make functional programming more palatable to the parenthesis-challanged.
Continual development in programming languages is not only useful but essential for progress, but to dismiss the work carried out by a whole genre of computing isn't particularly helpful.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
In its original, somewhat radical form, Sapir-Whorf is obsolete, but from my linguist friends (I'm only an amateur, myself) I hear a weakened concept of it survives. I speak four Indo-European languages (and understand a few more), and there are many concepts which aren't easily translatable from one to the other; or at least can't be expressed without a lengthy explanation. So any given language doesn't necessarily limit what and how you can think, but it channels what you try to communicate into its own well-worn grooves.
Regarding programming languages, I'd say Sapir-Whorf is applicable in many circumstances. Once you learn, say, C++ templates, you can use them to solve certain classes of problems very easily, and this leads you to visualize a complex system in a different way. For several years I programmed a Burroughs 6700-series mainframe in a modified Algol, which had very powerful string find, search and replace commands - which actually mapped directly to the hardware - and this actually led me to work in a wholly different way from the way I did things before.
So a programming language channels your thinking and often even leads to the well-known syndrome of "To he who owns a hammer, the whole world looks like a nail". Yes, you could write a compiler in Object COBOL (known to its victims as "POST INCREMENT COBOL BY ONE"), but please don't ask me to...
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.
Historically all such attempts have either failed outright, or not been popular - witness the Ada language, which tried to be all things to all people. As long as we're limited to writing programs, or parts of programs, in text form I doubt we're going to see this. And 100% visual languages (like ProGraph) won't see wide acceptance until we get better gestural input devices.
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.
// 3DR
:)
:)
:) This gets me in unnecessary trouble.
The following is personal standpoint of course, and not representative of my current coding game project, or my company.
1. If you look deeper (I did), I start to think of George / 3DR as stealth feminists.
Of course, if I actually say that to George, I'd pissed him off big time.
They hired a "human coder" only because they need him/her. They need his/her code.
There are many companies that: "Hey, we should hire a woman to get more press. To improve our image."
But only 3DR: "We should hire this HUMAN because he/she is one of the best / most knowledgeable."
2. Duke
I like Duke for a long time before people start to tell me it is sexist.
Enjoying pornography, puns, bad jokes, is not demeaning to women.
Unless I think of myself as a pixlelated sprite stripper in the game.
Unless I think Duke represents (or is meant to) in any way the real world (then I may as well believe in Everquest and we are all elves and dwarfs).
Then, maybe I'd have some problems.
There is a "huge divide" of 1 make-belief world I (and most sane players) understand to be make-belief.
And sincere Katz-like genuinely concerned people believing seriously in "the reality that men and women are different."
Katz (sorry Katz) wasn't making a joke when he writes all those articles. He really believes in them.
Being a HUMAN who plays and enjoys games for many years, I have a very solid grasp on:
a. game -> fantasy
b. real world
When I choose to be Voldo in Soul Caliber, and not Xiao-Yu. I think to myself:
Voldo have a lot of sneaky feights that I can confuse a lot of players so that they don't even know where I am coming
not
I think of myself more like a male homosexual perverted Italian sex slave masochist, than a Chinese female acrobat
Note to newbie gamers: If you start applying real life prejudices to gaming, you are going to suck. It is like the movie "Matrix." Play with the "rules of the games", not your perception of reality.
You are welcome to email me off-line for further discussion on the above.
// "finally" etc.
It appears we are on the same page.
The issues are a lot less across gender divides.
It is a lot more on the true meaning of prejudices. Prejudices of all kinds.
Over-generalizations of a lot of human beings (male and female) that people don't know about.
What I battle is true prejudice, and I don't care if I am doing it for a man, or for a woman (or for myself, or my enemy, or for my friend).
Whenever I see someone makes 1 erroneous generalization (thus prejudice in the real meaning of the word), I have a nasty irrepresible need to right a wrong.
My view is prejudice, and over-generalization is not only annoying or unfair.
It perpetuates ignorance. It stifles progress to greater understanding or knowledge.
The particular Carmack bashing human should for example cease to gain greater insight in Quake rasterization implementation. The ones who see woman first and knowledge source second will cease learn more in math or code.
So thus I act locally to battle every minute pointless instance of true prejudice, of over-generalization.
You had heard of the movement of "random act of kindess"?
It would be nice if there is a:
1. "random act of enlightenment"
2. "random act against misinformation / over-generalization / true prejudice"
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.
I like reading Orwell - certainly I don't mean to dis the guy - but with regard to newspeak, he was just dead wrong. Since he was writing fiction, and since most of modern linguistics didn't exist at the time (and even if it had he probably wouldn't have known anything about it), I don't take it as a big deal.
I direct you to the Berlin and Kay study of colours, the perfect, near completely culture-neutral, test of this hypothesis. Finding a relevant URL will take some time, and I have code to write, so I assure you if you look at their papers for 1969 you will find the one in question.