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."
"
Your not first so dont lie -Your village called their idiot is missing. Teufel_Forelle
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
Also, don't buy any video cards until the video card companies make the video cards FREE and only charge money for support. That way, we won't have to pay for video cards! What a great idea!
Hardware limitations are one of the best ways to force software manufactures to improve their code.
Seems like this work could be cut in half by only allowing UNSIGNED integer types as array indexes. But then, I'm still miffed that Java only supports signed integer types... (Need to store a value between 0 and 255? Use a short!)
That aside, I think there are definitely conceptual things which do not translate well. Subtle differences in the flow, and logic of a language, definitely influence its use and application. Mandarin for instance, never conjugates verbs. Think about the implications of that for a moment...
-cwk.
Gimme an example of someone incapable of thinking something because of language.
I've been in academia. I spent the best years of my life in academia. I know that many disciplines teach the Sapir-Whorf hypothesis as received truth, but it is still wrong, wrong, wrong. Would you believe an English prof if he or she was taking about physics, while a physics prof said that it was incorrect? This is a subject where linguists should be trusted over literature profs and anthropologists.
Pinker convers the topic briefly in The Language Instinct. A search at linguistlist.org should find several discussions of the issue. I believe Berlin and Kay's book Basic Colour Terms is back in print, if you want to go to he horses mouth.
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
I was a bit suprised by that one as well. But then I realised that I should be happy that he actually mentioned Lisp, even negatively; AFAICT, most programmer's understanding of the Lisp stops at the parenthesis, and even then they assume it's Scheme (or "that scripting language").
;-), but until then it will cast aside as a research project in the minds of most Real World Prgrammers.
I'm sure that one day Lisp will once again be recognized for all that it is (hurry up TUNES
'C' is like math: use it and leave it alone. It's just a notation, it won't make problems any easier. We can only deal with so much abstraction.. C++ already showed how poor humans end up wasting their time trying to get around a language before being able to deal with the actual problem.
Also game programmers should try to cool off for a minute and realize that they are just devoted coders that happen to work in a popoular field.
ciaox
> essentially you're 90% of the way there.
;)
Yes -- you're 90% of the way to the current state of the art with object-oriented languages.
I guess what I am arguing for (and I think what Tim is, too) is for parametric *types*. Sure, there are lots of casting hacks one can do with C and even java, but these are difficult to support in the long run because there isn't any checking by the compiler. After all, everything gets turned into machine code in the end. In ML, qsort might have the type:
qsort : 'a vector * ('a * 'a -> Order) -> 'a vector
The 'a (pronounced alpha) stand for an unknown but specific type -- all the arguments must agree on the type of the thing being sorted. (So we could sort vectors of ints, or vectors of strings, or even vectors of functions, but we have to supply a compatible sorting function).
The difference isn't much apparent here (you might just document your C code to specify that), but gets hairy quick in big systems -- to the point where the concept isn't used except when it's really the only way to be generic (qsort).
Static typing and safety also permits compiler optimizations unheard of with traditional languages.
Here's one concept I don't think is very easily expressed in C, though: function composition. How easy is it to write a function, which takes two functions, and returns a function that is their composition? In ML, that function "o" is just:
infix o
fun (f o g) x = f (g x)
.. this kind of use of higher order functions is pretty hard to do in C (very hard to debug), and, as it turns out, quite useful.
- Tom 7
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
notzero n = 1;
n--;
In other words, your just trading divide by zero generating an exception for addition/subtraction generating an exception... not really a big win, is it?
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.
I really don't feel he is arguing that faster machines shouldn't be required, he simply states that they are not required for most applications people are currently using on a day-to-day basis. Knowing this, he is trying to demonstrate how futher abstraction could lower development time and aid in maintenance without any notice on the part of the end user.
Give it a year :)
stop pretending ;)
We can't ALL be John Carmack. It amazes me how much strutting manliness enters the geeky domain of computer programming.
It's all about getting things done. You can have C/C++ until they pry it from your cold, dead fingers. I'm hacking away with Perl until something better comes along...
Much of what Tim says about computer languages shaping thought and design is motivated by a fundamental hacker ethic: Code reuse. Why reinvent the wheel?
This past year, I've been working on my first real-world production C++ project, and I have learned to truly appreciate templates. I find returning to Visual Basic frustrating now, because it doesn't have a concept of parameterized types. As a result, I find myself yanking code out of the archives, and adapting it for a project-specific class. The result is duplicated code all over the place, even with VB's COM-based Interface/Implementation metaphor. Oh, how I wish I could just say:
Dim Foo As Collection Of CBar
Instead, I have to create a specific CBars class that manually implements Collection. Which is a crock because there should be an ICollection interface I can Implement, but that's a whole 'nother rant.
Of course, when I was writing C code, I always complained that strings were so much easier in VB. Oh, well.
Keith Russell
OS != Religion
This sig intentionally left blank.
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/
I feel better now.
Save the whales. Feed the hungry. Free the mallocs.
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,
>It would be a huge mistake for developers to use perl for a large project. Why?
More importantly: dynamic scope.
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.
never seen a tech support guy who got any...
-- your knees hurt, don't they?
It's good to see that people in the industry feel somewhat like I do... After studying some different computer languages at college, I found out that none of them fully satisfied me, and most important, none of them explored the full potential of concepts like object orientation, etc, in a practical way.
I've been thinking a lot about the concepts that today's programming languages lack, maybe they'll end up in my (how's it called in English?) term paper (or something like that). I was thinking about some things among the lines of what Sweeney wrote, and another detail I always feel that is a key factor in productivity is the syntax. We all can get used to any syntax, as terrible as it can be, but some "traps" of an obscure syntax can be a pain to even an experienced programmer, not to speak of newcomers to a language.
Maybe this is not the right place to say those things, since the C and UNIX tradition walk hand in hand and I don't exactly feel that C is a great language in terms of syntax...
Saving keystrokes in expense of readability is a bad, bad thing.
And I don't believe that the ideal object-oriented language can be an extension of a procedural language, it has to be object-oriented from the bottom up (C++ and Java go down the drain here).
I really think that we need a new language, maybe it's about time for the development of a new language, this time in the "open-source spirit". Most languages were mostly created by one or two people, what about democratically define a standard for an 'open language' then implement it?
Would that be possible?
"I'm looking through you, where did you go?"
I disagree, but I will conceed that a weakened for of Sapir-Whorf is possible. I don't think people think within the paradigms of a language (in fact, I'm not sure what paradigms a language could have.)
So, my disagreement with a heavily weakened form of Sapir-Whorf is an opinion, not science.
If you can think of a good way to test it, many linguists will be interested to hear it. This whole discussion (while fun) is off-topic to the issue of computer languages. I just wanted to put a stop to some inaccurate folk linguistics, just as I would have if someone had said that eskimos have fifty words for snow.
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.
What are you doing with the other 6.25%?
His arguements PC vs. SGI are absolutely ridiculous. Any idiot can go to sgi.com and get the benchmarks and see that he is completely full of it. TNT was designed for Q3 fps... Its a bad comparison anyways.... an Octane/MXE will outperform any TNT graphics card, any day of the year.
C++ is my tounge, and I like it! Do seem to spend wayyy too much time on structure, rather than actually programming though. oh well.
**This message was brought to you by the letters N, T and the number 666**
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.
His C=A+B argument is a good example. The function which adds an element of A to an element of B incurs overhead because it is a function. If you make special allowances for the list-of cases then you have just undid the abstraction. Yes, optimizers can do good things, but they only work so far.
Uh, if your compiler and language are reasonably modern, this will incur no overhead whatsover. For example, the compiler will know that all these variables are arrays (or lists) and will generate the correct code to add them. No extra overhead is required over using a for loop instead.
Especially funny. Crash Bandicoot 1,2,3 is largely ;-)
written in Lisp. Sounds like a successful
"research" topic.
And I can't imagine that his VM is any faster than Java would have been. My machine runs Q3 fine, but if I load up more than 3 bots, it slows to a crawl from all the VM'd AI.
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.
Scheme is a neat little rendition of Lisp that, while better than many more popular languages, simply cannot match the power of 'real' Lisp. (IMO, of course.) While I'm happier with it than, say, C++, I would be very upset if it became the de facto Lisp in the world. Using the names synonymously just adds to the problem.
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.
Um, no. Questions about the interaction between language and cognitive processes are quite squarely linguistic and/or psychological questions. Philosophy typically considers questions of ethics, metaphysics, and epistemology.
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?
I think that they're playing the 'who can get the lowest karma score' game. Let children near computers and look what happens....
*Sigh*
--
The gift of death metal does not smile on the good looking.
There has been a significant amount of research that has demonstrated that OO simply doesn't work as promised. There is a real indication that the future is efficient platforms (linux, Apache, Oracle) with extension languages (perl, python).
In fifteen years I'll be 40 and most young programmers won't probably even know what Bresenham does or how to optimize a texture mapper (unless they're designing a new 3d card perhaps)...
It's a shame... I'm getting old and sentimental... ;)
(that does not mean I don't keep up with new developments ofcourse)
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.
Scripting languages tied to efficient platforms (linux, Apache, Oracle) are the future.
...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.
No he doesn't. He just says people are primarily buying faster machines for the games. Here's the quote: People don't need to buy new 800 MHz Athlon processors for running Microsoft Word or other business apps, or for web browsing. About two years ago, computers truly became "fast enough" for those applications. Today, it is primarily games which drive sales of faster CPU's and 3D accelerators. This got modded up? It's not a bad argument, but it makes me wonder if anyone (including the moderators) read the article.
Well, I'm not a linguist, so I don't really know. However, I personally don't believe it to be true, I often find myself limited by the English language in my thoughts (like, i'll want to use a word that simply doesn't exist). That, in and of itself doesn't prove anything.
However, if it were true that we were limited to only thinking in terms we already know, how would new words come about? In order for a new word to arise, and idea needs to come about. Take for example the word cyberspace or doublethink. Both concepts can be expressed in words that existed before them, however those words had to come from somewhere as well. It would certainly be possible to think up an ethereal 'space' inside computers and there data without knowing the actual term that describes it. If it were impossible to think up concepts that cannot be described in words, then why would we need to constantly make up new words?
[ c h a d o k e r e ]
ReadThe ReflectionEngine, a cyberpunk style n
According to SGI's site the IR has a fill rate of 7 Billion pixels/sec. You're $100 tnt2 won't come anywhere near that. More Mhz does not mean a better cpu. Look at he FPU performance of Alpha and MIPS chips, they still crush pentiums. An Onyx with a R10k cpu tears up a seti block in a few hours, how long does you average pIII take? If cheap PC video cards are so good, why do all the major companies still do heavy rendering on SGI's? PC hardware just doesn't scale well enough. If you want raw power the Origin 2000 servers scale to 128 cpus, and even they can be clustered for a total of 1024 cpus.
Only the State obtains its revenue by coercion. - Murray Rothbard
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?)
Chemists rely on physical principles to perform Chemistry, only their esoteric semantics and methods make it more efficient for solving the problems they deal with.
They aren't Physicists and neither are Engineers, Computer Programmers, or Butchers, although "physics" could describe the rules that govern their interaction with their subject matter.
The uber-language idea may be the same as trying to define all disciplines as inferior or "branches" of Physics, it is inefficient and ineffective to do so. There is too much knowledge and practical art to shove it all under one umbrella.
Having said that though, I agree with the Tim's endorsement of taking OOP further. Just because there is a place in this world for C, doesn't mean we should stop developing and refining new languages.
"Sig free in '03!"
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.
The hypothesis that Tim Sweeney presents as fact in the first paragraph ("When you read about linguistics, the study of human languages (not computer languages), a recurring theme is...") is considered to be a myth by most linguists.
Sorry I don't know of a web page explaining how Shapir-Whorf (as this hypothesis is called) has been discredited by evidence.
Zooko
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).
I want to find the Programmer's Stone. The language in which I can write this program:
while (1) {
do $everything;
}
"We're on a mission from Gahd."
--The Blues Brothers
"Moderation is good, in theory."
-Larry Wall
There is no K5 cabal.
I am not the real rusty.
I know Anna Wierzbicka firmly believes in her Lingua Mentalis (even if I'm sceptical) and she's still taken seriously. If she's right, even weak forms of Sapir-Whorf have to be false.
It is hard to say with certainty whether a person's language has any impact on how they think, but I have yet to find any concept that can't be understood and manipulated by a sufficiently intelligent speaker of another language. I don't think even the weak form is generally accepted these days, although I admit some linguists are still holding out for a weak form of the hypothesis.
I have to conceed that a desperately weakened for of Sapir-Whorf may be true, due to the difficulty of distinguishing cultural impact on thought from linguistic impact. But every clear case I know of has failed to show even the weak form.
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
C++ isn't the present of programming languages? I guess you're just trying to be "edgy" to get a reply. Okay, I'll reply. You're full of shit. Regardless of what you use, a large number of large corporations presently use C++ to make a large number of applications that they sell a large number of. Ever heard of Microsoft? Yeah, yeah, you try to hedge your bets by saying "no one uses it for object oriented programming" so that you can defend your argument by quibbling over the fine details of the definition of object oriented. But to put it briefly: you're full of shit.
It provides no functionality not in C++, doesn't make writing the same program in C++ significantly easier, and is butt-slow to boot.
Not exactly winning characteristics, eh?
I don't care if it's faster than when it was introduced. I care it's still way slower than compiled code.
Do the benchmarks yourself. Write a simple program the same way (same algo/data structure) in C++ and in Java. Run it with the best JITC you can find.
Do you think gamers who spend big bucks on fast CPUs and killer graphics cards will look kindly on you wasting their money by writing slow code?
...
I don't agree with everything Carmack does.
But offloading work from compiletime to runtime doesn't seem like a good idea at all if you're working on a system that's pushing the speed envelope already, by very nature.
I agree whole-heartedly.
All the features he listed as necessary for next generation languages are common features of functional languages. SML and Lisp have had parametric polymorphism for years. Persistence is so trivial in Lisp that it's a non-issue. Similarly, Lisp's macros set the definitive standard for meta-programming. Furthermore, functional languages like ML, Haskell or Clean set the standard for current type systems (Clean and SML/NJ are not toys).
In any case, it was interesting to see him basically dismiss Lisp (in particular) as an academic toy. Given the problems it's used to solve, I presume they'll appreciate being reminded of their youth. FWIW, I presume his definition of toy is *not* accepted in the market.
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
I guess you fall into the category of people that can't see farther because they can't think differently, like Tim Sweeney said. Probably you are too experienced and too involved in your way of programing that you will not admit that it could get much better. (better anyway than hacking togheter piece of code with perl...)
Guillaume Germain
---------------
cheers
hmmm...how familiar are you with cognitive science research i.e. metaphor theory, conceptual frameworks etc. lakoff, johnson, and friends. language _definitely_ impacts how we think. not a professional but its just too common-sense not to happen. of course chinese can understand say moral hazard but just like the referenced article was saying, if its not easily done its much less likely to get used.
-- your knees hurt, don't they?
Also, of what language relevance is the chosen OS? For example, I use Perl a lot under Windows NT. With the exception of OS-specific scripting languages (e.g., DCL under VMS), no correlation between OS and language choice should necessarily be assumed.
Perhaps it would be worthwhile for you to define (for yourself, at least) what you mean by application, and also to consider the how difficult it would be to truly determine the usage of languages to develop those applications, without having such a narrow definition of application as to border on unusable. Remember, the stereotypical Y2K step-in programmer worked on COBOL code...
Journey to Yandol
No Laughing Allowed!
There will always be a need for greater power and speed, Moore added. The software programmers can always use it. "We have a saying, Intel giveth and Microsoft taketh away."
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.
http://smalleiffel.loria.fr/
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."
I'm a professional programmer, and I assume that some of you are, too. As programmers, don't we know the difference between hardware, assembly, procedural and OOP? Aren't the descriptions offered in this article more in the "blatantly obvious" category? I was hoping for something more in-depth, I guess. This guy sounds like my boss trying to explain to a client what exactly they're paying for. His "insight" is not new. It's not even interesting. My response? "Well, duh."
now that you started - how many words for snow do they have? :-)
erik
...all excited, don't know why...
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.
The philosophers I've studied under would be a little disturbed to find out that you've decided that developmental psychology is an appropriate subject for them to study.
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.
It could be used in a game?
Ever had garbage collection start churning in the middle of a VSync?
Esperandi
Indeed. Thanks for making these points.
A number of commercial Playstation and N64 (!) games were written in a mixture of mostly-Lisp and some-C.
There have been small, fast Lisp implementations for a long time; it ran just fine on the earliest PCs. Lisp, Forth, and Smalltalk all have been made to run on tiny hardware (Palm, other PDAs just as examples).
It's always funny to see people write about Java and C++ as "object-oriented" languages, or how object-orientation "doesn't work", etc. If you want to see real OO at work, you have to look at Lisp and/or Smalltalk; even OO dialects of Forth. All of these can be compiled to native code...
First I agree, but the best part was the extremely rare correct use of, "begs the question." So nice to see it once and a while.
Sorry I misspelled "Sapir-Whorf".
Zooko
C++ was based on Simula. Read Bjarne Stroustrup's The Design and Evolution of C++.
SmallEiffel is making good progress. I don't
have the URL at hand.
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.
It depends on what you mean by 'word' (and what you mean by 'snow') but in the Inuktitut spoken in Iqaluit, I remember only two root words for snow. It think one of them was "qaniit" (or maybe "qanik"?) and the other one was "aput" (or maybe just "apu"?).
There were other words that made references to snow and ice, but so do far more than two words in English.
Also, remember that Inuktitut uses a lot more morphology than English. In theory, Inuktitut could be said to have an effectively infinite number of words for snow, since sometimes complex sentences are turned into single, long words - but in that sense, Inuktitut also has an infinite number of words for 'coffee.'
The Turing machine is the benchmark for logical completeness. When you write a language, it is either Turing complete, or it is not. If you have Turing completeness, then you have a "complete" language, that you can essentially make do whatever you want.
It is quite important to realize that this does not mean that YOU can do whatever you want, however. If you don't believe me, try recoding the linux kernel in assembly. The speed benefits will be amazing. Waste of time? Because you are incapable of formulating the complete logic system necessary to build a kernel. Assembly certainly has the power to tell the computer to do ANYTHING. You simply don't have the mental or time resource to command it properly in this case.
I'll comment less on the connection to human languages. There is a certainly a similarity, but I will leave it to those who claim to know linguists to debate this.
"How many thousands of lines of code would you have to write in C++ just to get this functionality? "
Well, none if you use MFC, this is built in...
BTW, Eiffel is great, I have to learn it, I'm glad to see someone else is watching it!
Esperandi
You speak English (I assume you're unilingual, if not, imagine the many folks on /. who are) yet you can clearly understand the difference between 'free as in speech' vs. 'free as in free beer.'
Your language has obviously not restricted your ability to think in this respect. Someone, somewhere, once upon a time, explained what they meant by 'free software' and now you have no trouble thinking clearly about it. The lack of a simple translation has no impact on your ability to think.
"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. "
You would find Eiffel very interesting, you ought to check it out!
Esperandi
The second Linux gets a free Eiffel compiler, the world will start to listen.
Which "limits him" to talk about functional languages?
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!
Correct. But that's not how we're supposed to design right? If you do a deep tree inheritance tree, then you're probably lost in it. That indicates, to my experience, just a bad design.
Fat classes subclassing over and over again. Like MFC. That sure doesn't work. The whole point of OO is to make things comprehensible and expressive.
Then I think we should stick to design principles such as Demeter's Law which says you shouldn't do any *far*, that is involving much indirection, they've formalized it, and calls, and furthermore no class should include more than n methods. Say 7 if you'd like to make a reference to 7+-2 law of perception. That's called Adaptive Programming, probably you've heard it though, it works considerably well.
Design patterns also work out. Personally I use the same patterns in radically differing projects. And surprisingly different than GOF implementations. I take C++ features such as template specializations and generic functions to be most useful for a concrete implementation of patterns, for instance singleton, or adaptor patterns... Writing compilers and interpreters also work well I guess, that is compilers / interpreters that your system uses to translate things into native language (such as C++)
--exa--
Eiffel big on perfomance? Thats a joke. Its a really nifty language, but it makes Java look like a speed demon in comparison.
We are talking about Sapir-Whorfe, right? The influence of language on thought? (What there is of it, anyway.) I'll make it clear for you: This is not philosophy.
As for the shortness of my comment, you seem to have a personal vendetta against linguistics, so I didn't think you'd take any notice of any arguments, no matter how reasonable. It appears I was right.
I'm currently setting up a live masturbation web cam. I'll spam slashdot when I get it done so you'll know :-) btw lililililillililililil in Natalie Portmans pants!!!!
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.
that the realm of philosophy is those areas that haven't proven amenable to scientific investigation
;-) Culture B may have a helluva time wrapping their brains around A's subtle ganulations of social-emotional states (to pick an example at random), but I don't believe we can a priori comclude than B can't experience subtle social emotions. They may not even realise they can--sinse they lack the concept with which to express their experience--but it doesn't seem contradictory to say that they can still have those thoughts.
Hmm, that's not actually what I was thinking. I'm not sure if I would even draw a line between the two, considering how fluid science has become, and how 'scientific' philosophy has become. Psychology, after all, is barely even a science if we take physics as a prototype, and physics itself is becoming more like a branch of philosophy all the time. (Witness quantum mechanics, which was formulated as an epistemological theory.) It might be more rewarding to place philosophy in the same catagory as mathematics, hovering between science and the arts, but serving as a backbone for the former (and in this case, the latter as well).
a statement ammenable to scientific proof
Agreed. To the best of my knowledge, cogpsy and linguistics supports that intuition as well--there are certainly statements that can be made in, e.g., Japanese, that I'll never be able to fully comprehend, or even begin to understand. On top of that, language almost certainly can't be formalized, so we can expect it to remain a 'dirty' field. This is not to say that one couldn't come up with a crufty-but-workable way of translating the term, though.
the theory that language and thought are a one-to-one transformation.
Once again I agree. Taking the Language of Thought literally would simply be insane, and is a position that, AFAIK, is very unpopular.
Circling back around to the beginning of this thread, while I agree that language restricts what can be expressed and, because language is so intwined with thought, what one can think about easily, I don't believe it follows that there are thoughts that people in culture A can have that those in culture B cannot simply because their languages are different. (Hopefully B can't express "run-on sentence" either.
OTOH, the opposite doesn't seem contradictory either. Time to call in the scientists, methinks.
I think you are pretty correct. Working ina department that is over 50% chinese. I would say that there are definate ideas that don't translate. A good example: the issue about the brother of the UnaBomber turning him in. One of the Chinese folks said that would never ever happen in China for it would bring too much shame to the family! I was astonished. When it was pointed out that the UnaBomber was a murder, it made no consequence to the person whatsoever.
Turning in a murder VS. family honor?
Definatly a conceptual difference!
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
No "and" before "calls". I meant "any *far* calls" Sorry.
--exa--
Sorry, I'm in a hurry to get to dinner, so I'll just use TUNES review: go here and read "Cons" (ironic, eh?). If it's not there, add "no decent object system" (AFAIK).
I'll look into that card, thanks to all of you!
C'est clair que l'anglais a emprunté pas mal de mots du francais, mais la question, c'est s'il a emprunté les sens qui y sont liés.
Borrowing words happens. Germans call computers "Komputer", but it doesn't mean that until German had a word for "computer," Germans were incapable of thinking about computers. As soon as the first German was introduced to a computer (perhaps even earlier) the concept became thinkable, even if he (probably he not she) had to borrow a word to say it.
"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.
I greatly respect Tim's recent article on programming languages, because leading game developers do hold great influential power in the software industry. However, I found Tim's article, "A Critical Look at Programming Languages" to be very interesting, yet flawed. The reason that his article is flawed stems from one of his opening disclaimers: "You will also notice an entire category of languages missing, the functional languages represented by Lisp, Haskell, and Miranda; they are interesting research topics, but we're sticking to languages with ample applicability to shipping applications and games. This article is about practice, not theory." In this statement, he makes a claim that his article is concerned with "practice", not theory, and he also implies with this statement, that functional programming languages are more theory than they are practical programming languages. This message is not meant to knock anyone, and it is especially not supposed to knock Tim Sweeney. I dig Tim's games, and I respect him as a fellow programmer. I am writing this addition/correction mainly because Tim said, 'In writing this, my goal is to get programmers thinking and talking about this topic, and partly to "sew the seeds of discontent.'" I will help sew the seeds the best I can... Hopefully it will help bring about good changes. Now, back to Tim's statement that he is "concerned with practice, not theory". Tim's entire article leads up to the theory of what the next big programming language will/should have. The entire construct of his article contradicts this statement in his opening disclaimer. Not only that, but he goes on to name cool things for the "next big programming language". One of these crucial attributes of the "next big programming language", according to Tim, is, "The notion of function calling (in this case, calling the '+' function) needs to be higher-order; it needs to be able to operate over elements of an arbitrary domain. In this case, the domain is pairwise elements of an array. But this concept is radically more general -- it can support (warning: scary technical terms) function composition and the monadic combinators of Haskell", but wait a second Tim!!! Hold on here. Higher-order functions are a fundamental concept in modern functional programming. What about your practice over theory bit? Another strange thing is how Tim goes onto describe many other features that are seen in modern logic constraint based programming languages, such as defining relationships between objects. Logic constraint programming is another category of languages that Tim neglected to mention. Yes, I am not a good writer. Sorry. Hopefully you got some info out of my rant. I will close with my claim of the next big thing as far as programming languages go. It's a language called "Mozart-Oz". It contains all of the neat features that Tim described for the next generation of programming languages. It is an object oriented, functional, logic constraint programming language. The language, virtual machine, and APIs are the fruit of over a decade of research! It is all available under an open source license, which is BSD-like. The Mozart SDK also comes with tons of tutorials and documentation. If anyone is interested in programming in a real language that exists now, a language that fits the mold of Tim's prediction of the next big thing... head on over to: www.mozart-oz.org, and download the Mozart SDK... see for yourself.
I found it quite ironic that he dissed lisp, then the first great new "feature" he looks forward to is mapcar.
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.
www.mozart-oz.org
OH OH OH!!!! This is natalie portman, oh man Rob just gave me the most amazing orgasm!!! I love linux, No daddy I won'tsuck you tonight NO NO NO!!!!
sorry anyway I love slashdot and I want to suck the penis of all ACs!!!
I don't know about him, but I believe in technology for technology's sake. Thomas Jefferson believed that the more advanced and educated a society got the more equal and democratic it would become.
Off the topic of linguistics, but on the topic of Orwell:
Some would argue that 1984 was "borrowed" from an earlier work by the Russian author, Yevgeny Zamyatin, entitled "We" written 1919-1920. It's an incredible read that some have claimed is artistically superior to 1984 and Huxley's Brave New World. If you enjoyed 1984, pick up 'We' and give it a shot.
...actually, this is somewhat on the topic of linguistics. I believe that the creative process that goes into the formation of a novel (or the reformation of an existing theme from another language) proves the point that the human mind can shape abstract concepts into concrete terms. A talented author has a more developed linguistic skill-set for accomplishing this task. While more complex than the creation of a single word, I believe the leap from descriptive-word to descriptive-sentence to paragraph to essay to novel is a valid leap in this case.
http://www.gwydiondylan.org/
Its not copyrights or anything, but according to the official ZZT webpage (www.epicgames.com/zzt.htm) Tim lost the code in a crash! Damn!
Esperandi
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
Dude, you rool!
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.
Apparently I don't understand a few things. Could someone explain virtual classes a little more? I can't see why you would need to subclass the entire game engine, and then extend the Actor class... why don't you just add the new variable right into the Actor class to begin with? There would be no cut-and-pasting of code there, at least not with the language I use. You'd get the new variable in Actor and all subclasses of Actor. And, you would immediately get that variable in every existing instance of Actor, and instances of Actor's subclasses as well. In fact, it would even work if the game was running at the time.
No kidding, Mozart is awesome!
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
eiffel's not necessarily proprietary. a group
in france is writing the smalleiffel compiler. . .
makin' pretty good progress as well.
But, wouldn't choice of language affect time and price of projects?
E.g. would you accept, say $1000 as a fair price on your time for a simple web server in C?
How about as a price for a web server written in assembly?
What about a program that took a text file, found all of the instances of an arbitrary regular expression, and printed those lines? How much time would that take you?
If you were to implement that in assembly, C, perl, or if you could call grep or a function out the POSIX regex code, that would influence your time estimate, right?
I think the point that Tim was really trying to make is more pragmatic than "there are unthinkable things in assembly language, or C, or C++", but more of "certain things may be impractical, time-consuming, or error prone in this or that language, so I will attempt to restructure the requirements to avoid that problem", or conversely, "certain things may be so simple or easy to do that I will do them this way, and this will have these other nice side effects".
For example, if it were to take you 6 years to write a game in such and so a way, I suspect many game companies would either cancel or cut the project, because economically they wouldn't be able to support 6 years of development without a product, and by the time they had gotten 3 years in, the industry may have made another radical turn.
So if there was some language development which were to give them an order of magnitude of improvement in production speed (not that I believe that the next language development will do that, but think about the transition from digital logic to assembly, which probably did), then 6 years -> 3/5th year -> 7-8 months, which probably is within the realm of a "conceivable" (economically feasable) development cycle.
So, in the practical, economic/time POV, there remains the hope that a language will give you more leverage, and that will bring things that were outside of the realm of practicality (not possibility) into range.
I realize that your beef is mostly with Sapir-Whorf, but I think that this is more of what the author was trying to get at.
Class is an English word with many meanings.
Besides, inclusion of OO concepts where appropriate is beneficial, I don't dispute that. Pure OO enforced by the language is a pain in the ass.
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
Oh, I dunno. We use Octanes at work, and they're really not that good these days. On the other hand, maybe we're just pushing a lot of polys. :)
On another note, we just did some performance tests of an Octane vs. an HP Visual Workstation (or whatever the hell they're called). The HP actually kicked the Octane's butt in terms of framerate. :-b
I can write a toy language that is incapable of doing certain things.
However, assuming C is Turing complete (since I can write a Turing machine in C, I assume it must by definition be complete), I should be able to do anything in it. There is, therefore, no logical reason why choice of language should influence choice of projects. Now, as you pointed out, that doesn't mean I would want to write the Linux kernel in assembly - but it doesn't mean that if I had only assembly language to work with, the idea of the Linux kernel would never occur to me. (This is all hypothetical - I don't write kernels and I doubt I personally would ever write one, in C or any other language. That has nothing to do with the choice of language, it's an admission of my own limited experience and skill.)
However, I'll conceed that empirical analysis of programmers' habits could prove me wrong. There may be influences that I don't see. That's why I expressed scepticism about the conclusion (as far as computer languages go) not hostility (as I have with regard to the same conclusion about human languages.)
No, I'm not going to say that speed becomes decreasingly important as computing technology becomes faster.
This reminds me of the C vs C++ situation years ago. A few C programmers were complaining that the same program written in C++ runs three times as slow, naming the "damned abstraction" as the cause. The true cause, however, was the programmers' incompetence (used pass-by-value instead of pass-by-reference a number of times, kept using post-(in|de)crement for complex classes, etc) and the compilers' immaturity (only recent C++ compilers have truly advanced optimization techniques that look beyond assembly optimization level).
When you abstract something, amongst other things, you move gory details from the hands of the programmer to the tool. What this means is that not only "implementation-of-abstraction" details move from the programmer to the programming language & the compiler, but also optimization moves from the programmer to the compiler.
For example, take C++'s virtal functions. Any savvy C++ programmers knows how these virtual functions are really implemented in most compilers. Any experienced C programmer can whip out a struct with virtual-table-like "virtual functions", which, if optimized by him/her to death, may end up being slightly faster than the same thing in C++. A point here would be that the same thing in C++ ends up to be pretty damn fast without the programmer having to do any sort of optimization.
That is not the main point however. The main point is that the computer technology evolves all the time. Programming languages have evolved, through abstraction, from machine-instruction-level to procedural to object-oriented. The task of nitty-gritty optimization has evolved from trivial assembler-level optimization to complex optimization that must know how the program behaves to properly optimize it (e.g. must know the scope of an object, etc.) The optimization itself became more abstract!
Thus, as things evolve, the optimization "layer" will move along with the abstraction layer (from the programmer to the tool). We also have intelligent systems that optimize the program while it's running (an example here would be the Crusoe processor, although it's not that complex of such an optimizer), using special techniques that modify the code being ran to make the program run fastest for whatever task it's currently doing *now* (I'm not going to go in detail what sort of things can be done).
Therefore, I don't worry about performance at all. Give me a well-thought-out language that abstracts better, hides more redundant/gory detail from me and makes me more productive and I'll use it. I'll use it without much concern for speed because I know that if I use the features correctly, the speed will keep up.
Note that no optimizer can optimize bad design. With assembler and C, both good and bad designs were just as fast. With C++, bad design begins to reflect on the program's performance. With whatever higher-level languages may come, I'm sure that the gap in performance between good design and stupid/bad/not-well-thought-out design will continually increase.
Off the tank now.
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.
Yeah. Whatever.
Sheesh.
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
For example, Delphi uses Object Pascal, which is pretty much of a kludge of a language - but the Visual Component Library is very well designed, and makes business apps (not games, admittedly) easy to do.... Java has some excellent libraries (e.g. the Collections framework which is near what Sweeny was describing) and some very poor ones (i/o comes to mind). Choose the language according to the libraries available, not what could be implemented in it.
I was wondering when someone would point that out.
I use Windows for my dialup, because my Unix boxen don't like my ISP and my family doesn't like Unix. The comment was most aimed at the resulting quoting problem.
As for philosophy, to be honest you'd have to have suffered some severe head trauma to believe that philosphy can hold a monopoly on the mind. It most certainly can contribute a great deal--that is, in fact, my job at the moment--but we have to make room for neuroscience and psychology (the latter having been a branch of philosophy until recently, if that makes you feel better). The result of this cooperation is progress, both in science and philosophy; progress which, for some reason, seems to disturb some philosophers. I am not one of them, however, and I stand by my statement.
Well, last time I checked, USA law dosen't have much to say about free speech vs. free beer, aside from that the author can do whatever he or she is so inclined.
Mostly the free speech/free beer thing is Richard Stallman's invention. And unfortunately, I don't have my french-english dictionary on-hand, but at the very least, libre is much closer to what we mean when we say free software than is gratis.
The point here is that both terms (free software and open source) are confusing to the public in general, as well as companies like sun. The fact that there is no seperate word to connotate 'free as in speech', allows, for example, microsoft to call IE Free Software.
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.
Getting closer in speed, but not really in featureset.
There are a number of features that SGIs have that would be very useful:
* Higher resolution color depth. i.e. >8 bits per component.
* Better support for more (or less) than 3 or 4 components per pixel. (luminance, luminance-alpha, 16bit alpha, etc...)
* Full support for the GL pixel pipeline.
* Full support for GL 1.2 imaging extensions.
* Better stress/framerate scalability. Part of this is a software issue, part of it is a hardware issue.
* Better support for performance profiling registers.
* Better support for multi-buffer and multi-pipe rendering.
* Better digital video support (the SGI media buffer).
The point is that SGI wasn't just good at fast graphics hardware, they were good at fast, feature complete graphics systems. PC 3D people haven't figured that out because they were too busy letting someone else (OGLARB or MSD3D) innovate the hardware-software interface. I hope that someone in the PC 3D industry steps up an actually innovates on the software/interface side of things. NVIDIA is starting to do this, but they still don't have it down quite yet. Maybe the SGI/NVIDIA settlement will help this out.
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
Pinker is a big name psycholinuist at MIT and his book documents lots of reasons that I don't remember as to why Spiro-Whorf is totally wrong
GNU's implementation is called SmallEiffel and runs on Linux and many other operating systems. Bertrand Meyer's ISE Eiffel which offers the ease of Delphi development is available for Windows and Linux. It is a gem. A great resource for those interested in Eiffel is the online Eiffel Liberty Journal. In my opinion there are very few languages which offer direct support for quality software engineering. Ada, Sather, and Eiffel would certainly be near the top of my list.
Scheme is Lisp.
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
He obviously has never used lisp, or he would know that all the things he wants in a language are already present in lisp.
Actually a mix of ML and lisp in my opinion would be really handy... (with lisp syntax of course
Yeah, I guess "really, truly" wasn't all that clear. I meant the kind of compilation that you can't do when every type is resolved at runtime. Some definition that includes "javac"!
...and try working at a compiler company. I spent 6 years at Borland learning the real process behind developing new languages. I think he would greatly benefit from it - as would any compiler company that was lucky enough to procure his services! Hey Tim - go make the next language. I'll try it out.
The fact that all of the things that Tim says are coming in the next decade are available and possible /now/ in the set of languages he dismisses so casually in the first decade really told me everything I needed to know about his mindset going in.
/better algorithms/ that can be expressed and realized with the functiuonal languages.
"I can't be bothered to learn these Ivory Tower languages, so I'll just say I reviewed and discarded them as 'not good enough.'"
Pretty frustrating to me, especially when you recognize that the OCaml and GHC compilers (for OCAML and Haskell, respectively) have been known to create faster binaries than C on analogous algorithms. This leaves aside the whole field of
-- Riding the Winds of Fires Lit in Ancient Days
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.
Here's a link to the GNU Eiffel Compiler. It looks great! + it includes an Eiffel to C copiler. I think I read somewhere that emacs supports it by default if your source files are *.e
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"?
http://smalleiffel.loria.fr/
Why don't you try and catch up on some 20th-century linguistics? It's all in there.
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.
[
I am sick of my annoyed posts too. I found a way to shut up.
/. would be blank.
/. loads faster. :) )
I blocked all news a couple of days ago.
I shall never see any annoying chick news (and all tech news too) and thus never respond to anything that annoys me.
I am continually locking out things that annoy me, that goad me to post dorky posts. Every time an item causes me to post dork, I block the entire category.
Eventually either I would never see anything that annoys me, and never responds with dork.
Or
Either way, CY dork posts will quickly go away. I will be happier. Many like you will be happier. (And I think
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?
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. As ancient as it is, Lisp (and a lot of the other functional languages he dismisses) has a lot of advantages over even his proprosed "C++ with templates done right." Like lambda expressions, which let you make up new functions on the fly (very handy for AI).
And what about Python? Why does everyone ignore Python for Java, when Python is such a cleaner design, and easier to use. And not subject to the whims of a single company.
Furthermore, Lisp and Python are interpreted, which means you can generate and load extra code at run-time. Data files can have program chunks, and it becomes easier not only to create new data packs, but to add new features into that data while still using the original engine. Plus advanced users can have scriptable config files and preferences, and have much better ability to do things like bind a key to a complex set of actions.
I think he ignores these, and other languages, because they are slow. But you don't need to write the whole application in these languages. If you code the graphics and other intense aspects of the game in C, you can make those into a module for your higher-level language of choice, thus getting the best of both speed and flexibility. This is the way things are done now, with most games being all C with optimized bits of assembly, just at a higher level. The logical progression is not to extend new ides to C, but to write a language that expresses those ideas truly naturally, and use that except where speed is important.
It seems that in his history of languages, Sweeney fell victim to his own observed inability to switch languages. He still thinks in terms of C. I would agree with the progression from circuits to assembly to C, but the next logical step is most certainly not C++. That's the equivalent of an assembly programmer realizing the concept of funtions and data types, and building a whole suite of assembly macros to implement this concept. It works, but it's a hack. And Java is a hack on a hack with many other problems as well (but that way lies religious issues). No, the succesor in this model to C would be Simula or Smalltalk. And these languages are already more powerful than his proposed next generation language. The object oriented concept supported parametric polymorphism and virtual classes from the start, and it just wasn't implemented properly in C++. If you really want to know what the next generation of languages is, you need to look outside the box, and think of something genuinely new, which is of course genuinely difficult. But I hope that whoever comes up with it first won't hack it onto the current most popular language, but will keep it pure.
--
foof - Lisper, Smalltalker, and all around poor speaker.
But you would agree that a number of features available on SGIs would be useful, no? (I listed some on my wish list elsewhere in this discussion... like higher color depth in the pixel/texel pipeline, etc...)
I've always liked SGIs for the featureset more than the performance. Even an SGI maximum impact (which barely accelerated texturing) was more useful than a Voodoo2 (which was the PC3D I had at the time). Similarly, an O2 has features that would be great on a GeForce based card like the media buffer. However, my TNT2 based PC can outperform my O2 on a number of applications that I use everyday.
Most PC3D is designed toward the boxcopy and the software side of the IHVs solution is lost in marketing somewhere.
Well, the "weak" Sapir-Whorf is generally accepted to be true in some form, just nowhere near as dramatically as in the "strong" S-W. But even so, saying "language influences thought" is like saying "gravity pulls on stuff"; it's right, but it doesn't explain anything that you didn't already know.
No, Scheme is a member of the Lisp family, just like Common Lisp and GOOL (Game Object-oriented Lisp), which was used in Crash Bandicoot.
~~~~~~~~~
auntfloyd
Interface inheritance is better, using empty base classes with pure virtual functions. You can mix those in and get those method contracts matched properly.
Or give up C++ and program in Java, where you don't have these nasty compiler problems. ;)
-Chris
shut the fuck up already, you pedantic piece of shit.
Looks likes someone has solved GNU's problem of free (as in beer) and free (as in speech). Simply append each use of the word 'free' with either 'beer' or 'speech' and voila! No confusion.
Next, I would like some beer, for free(beer).
I love C++, the next language will have to be a LOT better for me to go learn a new one ;)
Um, not if you're even a semi-decent C++ programmer. One of the problems with from a flexibility POV is that C++ doesn't make virtual functions unless you tell it to... this is precisely to avoid the "extra layers of indirection" if you're not using them.
The single level of indirection (due to the vtable lookup) is there with C or C++ if you're using polymorphism. The cost is minimal unless it causes a cache miss.
> using all your latest multiple inheritance, operator overloading etc. my be easier to develop and debug
Or it might not since C++ has such a bad version of parametric polymorphism.
> all that extra function call overhead and indiretion
Templates and operator overloading don't have any overhead... (well, templates have space overhead which can lead to extra cache misses, etc...)
BTW: Kim Bruce's work on statically typing and avoiding dynamic type-checks is worth looking at in this regard.
Do, whatever you like. But If youre ebarased by your posts it might simply be a better idea to control your keyboard then to limit your mind... But, that's just me :)
Amber Yuan (--ell7)
"and dear god does this website suck now." -- CmdrTaco
I don't know why you think Eiffel is proprietary.... its portable as all get out and there are dozens of different compilers for different platforms including an Open Source GPL one someone replied to you about....
Esperandi
Put down the crack pipe son...
Hey... what do ya expect! Guy codes games and has no formal education. So basically he knows jack shit.
Those game dudes think they know shit just coz they can code hardware accelerated games.
Let me reitterate this... you know Jack Shit Mr. Swiney.
AC
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)
I doubt it. Too much of Japanese--or most languages for that matter--are tied up the culture, in the way you learn, etc. While I could certainly learn to use the language correctly, I wouldn't really understand the meaning of the words in the same way as a native speaker. Saying that kami are kinda like gods but not quite may allow me to use the word in conversation, but it doesn't mean that I'll really understand what they are. That difference has nothing to do with language and everything to do with culture.
It all comes down to this simple fact: "I quake therefore I am". It's wonderful to that your average gamer by playing video games on the computer is helping to full new technology. Or maybe this is just a way to justify droping $200 on a new video card everytime the new version of quake is released. I dunno : )
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
Thanks man, this is great! I had read there were no free compilers available somewhere and just took that as truth, and this thing has been around since 95!
The reason why I said the world would listen when it was available for Linux even though I don't use it was because I figured software workshops making huge applications are just getting started for Linux and Eiffel is MADE for huge projects with large teams that need to compile down to extremely efficient executables. In win32 I assume most development teams are too entrenched in whatever they're using already to switch over to something like Eiffel (its not a bad thing, it would simplycost too much in retraining and the benefits would take too long to realize, it wouldn't be sensible)
Esperandi
Everyone, go to the link this man posted and learn Eiffel!
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
No, his virtual class "crap" isn't fluff, just a poor choice of words. I have done classes in C, so I KNOW you can do virtual classes in C++/Java. Just not without TONS of comments. The whole idea is to make a programming language where comments are unnecessary.
Comments from a deranged lunatic who thinks he's cleaver.
I saw "Tim Sweeney" and spent half an hour trying to think of ZZT. Thanks. I played World of ZZT to no end back in the day when you could get shareware mailed to your house on 5.25 floppies. If you let your shareware postage subscription run out, you can download all those old ZZT games at zzt.org
The two toughest performance problems in Java are math (but C doesn't do a great job either, unless you explicitly walk the matricies in the right direction) and graphics (because all of the graphics bitblt crap goes on in user space instead of in the kernel like all of the other Win32 applications). As for good books on VMs in general, collecting dust on my bookshelf is the Ronald Mak book "Writing Compilers and Interpreters". Might be worth a look (but don't quote me-- I bought it on a whim).
While the author is quite correct that there is a need to move towards a higher layer of abstraction that simply "classes", he neglects to consider that such constructs already exist in many languages.
.012 cents...
Consider his model/view example (which by the way neglects the importance of a third controller class). Suppose you wrote a framework that manipulated Models and Views, and you wanted to allow extension.
This is a perfect situation for applying the AbstractFactory design pattern. (See Design Patterns, Elements of Reusable Object Oriented Design for more information). Essentially, here is the solution in Java:
public interface ModelViewFactory {
public Model createModel();
public View createView();
}
public class SpreadsheetModelViewFactory {
public Model createModel() {
return new SpreadsheetModel();
}
public View createView() {
return new SpreadsheetView();
}
}
Now let's consider the DukeNukeEmEngine example in Java:
public class DukeNukeEmEngineFactory extends UnrealEngineFactory {
public Actor createActor() {
return new UnrealEngineActor() {
private Object newVariable;
};
}
}
Viola, we have now added a new variable to hundreds of thousands of actors in the system. Regarding persistence, it is very easy to develop frameworks using introspection to easily support forward/backward compatibility.
Now let me pose a challenge to Tim: suppose I wanted to write SuperEngine which took some of the best features of two different implementations of Engine? For example suppose I want DukeNukeEm.Actor, and Quake.Map? In Java, I can easily write:
public class SuperEngineFactory implements EngineFactory {
public Actor createActor() {
return _dukeNukeEm.createActor();
}
public Map createMap() {
return _quake.createMap();
}
private EngineFactory _dukeNukeEm = new DukeNukeEmFactory();
private EngineFactory _quake = new QuakeFactory();
}
While the article does raise some interesting points, it also shamelessly plugs UnrealScript, a vertical language particularly tailored towards a game engine, touting features that could easily be be built into many existing languages.
In truth, there is no such thing as a perfect language and new features will continue to evolve over time. However let's not forget that specialization comes at the cost of generalization. When was the last time you heard someone wanting to write a spreadsheet in UnrealScript?
My
Don't get me wrong, I have no problem with Scheme per se, and many of implementations are excellent. I'd take any of the Lisp dialects over most other languages. I just don't think that Scheme is the best Lisp has the offer; the same goes for Common Lisp, EuLisp or any of the other current standards. Looking at some of the more arcane versions (I'm trying to find BC Smith's {2,3}-Lisp at the moment), I can see a lot of room for improvement (or perfection; whatever).
Anyhoo, it wasn't my intention to start a language war, so I'm just going to shut up now.
VB is considered a 'higher level' language and I have yet to see it run on anything other than Winblows.
LRJ
You left out Fortran and LISP.
Maybe he should look at http://www.franz.com/apps/gd.main.html for a sample of what's being done with this "research topic"
~~~~~~~~~
auntfloyd
>And I won't care how slow it is. Ahhh, the difference between a support person and an end user who want all data instantly.
I'm working on a compiler for a programming language - Modula 3 - which made size (50 pages) a design goal. I don't have the foggest whether many things are legal or not. I understand that Pascal had many problems because the PUMR didn't explain things. Usually a thin book is just "we didn't bother getting into details because (a) we didn't want to or (b) we know all the details and don't realize we're leaving them out of the standard."
that $100 graphics chips outperform $100k Silicon Graphics workstations? Stop smoking that crack, boy.
This is another example of that free-market/technology boosterism that spews from the mouths of those that least understand technology but think they know everything.
The languages that Sweeney mentioned at the beginning of the essay but said he wasn't going to mention because they weren't "mainstream" enough, such as Lisp, Haskell (and logic languages like Prolog and Mercury), have been doing all these things for a long time. Some of them (Common Lisp for example) have extremely developed and powerful compilers. In an earlier essay, Sweeney mentioned that the "mainstream" programming world lags behind the "academic" programming world by quite a bit. Maybe they're so slow to catch on for the same reason someone at work I know refuses to use a reasonable shell and hit tab to complete filenames rather than laboriously cut and paste everything. And there's lots of serious mainstream use of at least Common Lisp.
There are a lot of really cool, really powerful languages out there *right* *now*, and they might require you to fundamentally change your method of thinking. Perhaps there is resistance to this because it's like having to learn programming all over again, but I *like* doing that.
perl is mostly a rehash of C, awk, shell, and random other stuff. It was designed to be "practical" which seems to be synonymous with "backward looking". Not that perl would be a bad language if it had a reasonable syntax, but it doesn't, so I guess there's nothing really to recommend it, other than ubiquity. python does a pretty good job of being "practical", I think.
If you're actually interested in languages, and ways to think about programming rather than writing the same old app the same old way, learn eiffel, haskell, scheme, mercury, etc. Even if you don't wind up using most of them very much, you won't regret broadening your mind.
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.
There is no way in hell that a $100 chip from 3DFX or Nvidia out-performs a $100,000 SGI, for that price you are looking at an Onyx2 system or and VERY max'd out Octane (maybe even a down payment on an Origin2000) which outperform those PC chips hundreds of times over. Not to mention their very optimized software; which is comming to Linux :)
vlax worte: That 5% was a concession to the handful of linguists (mostly anthropologists) who still take some portion of Sapir-Whorf seriously.
Give it a rest. Add the ethnographers, media theorists, cultural theorists, historians of science, etc. etc. etc. and together they far outnumber the hard linguists. As Daniel Chandler notes, there is a "broad acceptance" within academia of a weak version of the Sapir-Whorf hypothesis.
See: http://www.aber.ac.uk/~dgc/whorf.html
A lot of geeks resist the idea that language constrains reality because they can't bear the thought of their world being C++. :-7
Danny
Copyleft stops me from running off as many as I like?
Now that's what I call an argument.
I was under the impression that smalltalk was a basis for extending C to "C with classes" and then subsequently to C++.
You're almost right!
Objective-C is like C with Smalltalk's object model, that's probably what you've heard of ("C with classes"). C++ is different, and uses an object model similar to that of Simula. An OO purist will tell you that it's not really object-oriented, but that's more of a religious issue.
"Bernoulli was wrong. X proves that you can fill a vacuum, yet still it sucks." - Dennis Ritchie
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
I think you're rightfully angered, but it flat boggles my mind you're working at 3drealms - Duke3D was arguably one of the most sexist/mysogonistic games that gained wide appeal. I also can't help remembering stumbling upon a E3 picture page of one of the 3drealms owners which consisted of not much more than "Me with this boothbabe", zoomed in pictures of T&A, etc.
Facing frustration with just the general gaming world, it's this outsiders view is that 3Drealms would be one of the last places to work expecting to be treated as a human rather than a female. It'd be interesting to hear a response!
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
Um...that has about zero to do with Sapir-Whorf. You're way too far into the realm of cultural anthropology for it to be applicable.
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.
Sure, this was exactly my point. Or rather: Common Lisp is not the only Lisp language.
seriously. . . hello. . . . does nobody really understand available c++ libes?
--there are certainly statements that can be made in, e.g., Japanese, that I'll never be able to fully comprehend, or even begin to understand.
Well, what if you were to learn Japanese? Would that solve your problem. Japanese would have to be taught to you in English, therefore any Japanese concept could be understood by a native English speaker.
I've thought about that in the past, and wondered if there was anything that someone couldn't learn if they spent enough time studying a language, and I concluded that there wasn't. This is because a language has to be learned in the first place. We might learn more slowly then a baby, but we are still capable of learning. Whenever you have a word with subtle connotations, its always possible that even another person near you does not have the same. For a long time I was using a denotation of "hyperbole" that was completely incorrect, for example.
Amber Yuan (--ell7)
"and dear god does this website suck now." -- CmdrTaco
Heh, it's fun to go OT. :) ) to design good VM, and implement good VM. :)
In some ways it seems difficult (at least for me
What are the best way choose decent op codes for VM?
What are some caveats to VM implementation?
What are some tricks to coding good VM's?
Do understand my VM making ability to limited to the brute-force big look up table of code to execution. There *must* be a more intelligent way of putting a VM together by professionals than the way I hack them together.
Thanks for any VM information you would have.
No...the overhead isn't in the fact that the for loop is used. The overhead is in the fact that in a language like this guy describes, A and B aren't necesarily always arrays. They may be normal integers. And the compiler doesn't know, this is determined at runtime. If the compiler did know then most of the benifit of the logic model in this new language is useless, all it is is a typing shortcut (ala myInt++ as apposed to myInt = myInt +1....just a convenience thing). Since this is runtime determined, the code generated by this compiler ether uses a for loop whether you need it or not, wasting cycles on the vast majority of additions which are single numbers, or it determines whether it needs the for loop before hand with an if statement, wasting cycles all around. Abstraction does have a price.
C programmers that feel turned off from C++ by that article, don't be. Though he took a different approach from most C++-bashers (oh no! it's "bloated"!), it looks like he hasn't kept track of recent developments in C++. Templates are not the primitive feature they were in '94 and today, actually solve many of the problems he talks about.
First of all, he talks at length about having to make a loop to add the contents of 2 arrays. He suggests we should allow a construct such as "array3 = array1 + array2". Yes, the loop is annoying and error-prone. But his idea is seriously flawed! The problem is ambiguity. With such a construct, what exactly do we add? All the elements? The first element? There is no correct answer and such a construct can only lead to confusion.
Also, it does not provide a general enough solution. What if I want to add only half the elements in the array? I will have to write a loop anyway, thus the feature is too feeble.
So, I presume he didn't mean that literally.
C++ provides standard library components to solve exactly that sort of problem. With something like for_each(), I could've done that in a single line, without a loop, and what's more I could've chosen to add only half the elements in the array.
Oh, and by the way, with operator overloading it would be easy (but dumb, as stated earlier) to overload operator+() to add the contents of those arrays together.
And C++ already provides almost direct support for his "virtual class" concept. Simply create another inheritance hierarchy for the "virtual class", parralel to the first, with virtual functions used to read/write to its members. Although it means a bit more syntax, in the long wrong this will be a _good thing_ because you might find out you need to extend the parralel hierarchy separately from the original. Frankly I don't feel that this aspect of C++ needs any change at all.
The committee that standardized C++ includes many of the best language designers in the industry. I've found that C++ elegantly solves every problem I could throw at it. Before you clamor for new features, think about whether what you want to do can already be done by combining existing features of the language.
Broccolist
On another note, we just did some performance tests of an Octane vs. an HP Visual Workstation (or whatever the hell they're called). The HP actually kicked the Octane's butt in terms of framerate. :-b
I work for Ford, and am involved somewhat with the Unix workstation benchmarking. I can't give out any numbers, but Ford won't buy any new SGIs. Way too slow compared to HP and Sun. A PC with a decent high-end card (Like a Wildcat or HP's FX6) can get into the ballpark of an HP C3000, but there's no way a GeForce could do the same.
"I wince just thinking about the compile times that programs from such a language would take. " Hey, bud, dynamic binding makes it so that you don't have to recompile the original class that you sub-classed. So, you only have to wait for roughly four lines of code to parse. Yeah, that is still fast, even on a P166
Mozart, a programming language that's parametrically polymorphic. http://www.mozart-oz.org/
I think imperative languages are considered to be something of a dead end of optimization only by people who spell optimization with an "s" instead of a "z".
:)
Your American Imperative Optimizer,
nick
(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.
Virtual class var? That's just the Factory method design pattern. (see the Gang of 4 Design patterns book) - "Define an interface for creating an object, but let subclsses decide wich class to instantiate".
You can implement this in C++, Java, Delphi etc, so what's the big deal?
My Karma: ran over your Dogma
StrawberryFrog
If you can't exspress the idea of Kami in 1,000 words of english (or 1,000 words of japanes, for that matter.) then its probably not a consept that All japanese hold in common. Now, it may not be worth your time, but could still be done.
Sure, there might be huge amount of sublties in the language, but if there are those probably vary from person to person anyway. Remember, if its posible for a little japanese kid to learn what that word means, it should be posible for you as well.
Amber Yuan (--ell7)
"and dear god does this website suck now." -- CmdrTaco
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
Virtual classes... Isn't that just a fancy way of implementing the Factory pattern, or possibly the Strategy pattern?
It's called the State Pattern. Read a copy of Design Patterns and take a gander. His virtual class crap is just fluff.
Most of the things he talked about seemed to be from the object-oriented point of view. I don't know too much about Perl OO stuff, but I hear it's like Python's. Python has many of the advantages that he talks about, but it also has some disadvantages for what he's talking about. You would never write a game engine in Perl or Python. If you did, you would write lots of it in C, which would ruin most of the advantages he's talking about anyway. With dynamic lookup of methods and what-not, you get the flexibility he's talking about, but you pay for it in speed big time. Java and C++ aren't less flexible than Python and Perl because they suck; they're (really, truly) compiled languages, which makes them faster than dynamically typed languages. I guess a lot of his hopes will rely on fun stuff with compiler technology, won't it?
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?
Take a look at Blitz++. It does everything his article claims C++ can't.
I would say it's the kids who buy the games that have more influence than people realize.
I'm not saying he doesnt. In fact, I'm sure he knows C++ pretty well. But maybe he just doesn't explain himself very well, because he comes across as not understanding how to do various things in C++. He dismisses C++ out of hand as being 'unable to do' various things that are in fact incredibly easy to do in C++, and do them in a very general way (as he seems to describe) (e.g. C=A+B on arrays, and in fact on anything you like if you combine this with template classes and maybe a mixin if you're inclined to do things like that.) Maybe I just don't get what sort of amazing generality he is referring to.
He didnt explain very well at all what is so "flawed" about C++'s parametric class (templates) implementation. Instead he came across as sounding like he maybe once read through a chapter in a book on template classes and then never bothered to try them out.
Now, I have a lot of respect for Tim Sweeney, and I know he is extremely competent and I know he knows what he is talking about. He just doesn't explain himself too well. Instead of explaining technically his problems with C++ he comes across as someone who just has a bias against it.
Due to the high level of abstraction, compiler optimizations are a field of research. However, that's a price you pay for every step up the ladder.
Reminds me of "aspect oriented programming", look in functional languages, there it is. This phenomenon results from the desire to stick to C\C++ while having all the fancy stuff. Let go, welcome to the brave new world. :) Any language developed in order to what he asks for needs a solid theoretic base in mathematics and will end up as a functional language.
You can say functional languages are way out there, but how long did it take the masses to adopt full scale OO development?
And to break some bubbles, game developers are not on the front of software technology, that's still CS, not a matter how fast you can draw polygons.
Just look into the Unreal/UnreaTournament game. Open the UnrealEd. There you can look at the classtree. UnrealScript is the language of the Unreal Engine. You can not use it for anything else then enhanching the Unreal game. (But this is very easy)
See how much the definition of one word changes from person to person even in the same language? two the two of you the word means different thing. Words really have only (and can have only) generalized meanings between any two people. Those generalized meanings can be transferred to other languages. You may not get all the subtleties, but there is no guarantee that the guy next to you carries the same subtleties anyway.
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?
Well, I haven't but I'm sure the linguists wouldn't be saying that it wasn't true if they didn't have anything to back it up.
Amber Yuan (--ell7)
"and dear god does this website suck now." -- CmdrTaco
"Few people use C++ for object oriented programming"
Perhaps I'm the clueless one here, but this flies in the face of everything I know about the current state of the software development industry. Perhaps I might be more inclined to listen to your point if you could back this up by providing me with a reference to the source of your information; otherwise I might be inclined to irrationally believe that you boldly made that up simply because it is your own opinion.
The rest of your post makes a fair point, use the best language for the job.
- 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.
But there's a difference in what you influence. Influencing technology changes (which is what Sweeney is talking about here) is a completely different matter than influencing human psychology.
GNU's implementation is called SmallEiffel and runs on Linux and many other operating systems. Bertrand Meyer's ISE Eiffel which offers the ease of Delphi development is available for Windows and Linux. It is a gem. A great resource for those interested in Eiffel is the online Eiffel Liberty Journal.
The man has a point. Everything he discussed can be done with an appropriate application of design patterns.
Maybe look at www.alice.org. Kinda a cool.
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.
Is that a problem in the language itself or the speakers level of knowledge? Can a stone-age tribalist think about things his language might not have words/concepts for or experience with? He has no term for a rocket, spacesuit, oxygen, vacume, etc, but he could imagine a realistic trip to the moon. His level of technical detail might be sketchy, but so was such descriptions by early science fiction writers.
The current Slashdot moderation system is made by gay communists!
>
> object system that I rather like.
In terms of scalability for large projects this is true. I was just pointing out what seems to me to be the biggest problem with perl (historically, and to a lesser degree, today).
To me (and I've written big programs under both paradigms), "coding standards" which are enforced by the compiler (ie type system) are much, much more valuable than coding standards which are mandated by agreement, or even by assertions in code. (But don't fall into the trap of thinking that powerful type systems simply restrict the programmer
- Tom 7
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.
Ok, when I got to my first OO class, we read an article that basically said "If you know how to do procedural programming, you are ruined. You will now be stuck in old ways of thinking and be unable to grasp OO concepts that three year olds will intuitivly understand."
And now this - Java is soon dead, all hail the next generation languages. Damn, I'm 25 and still studying, but already I'm senile and obsolete.
But come to think if it, maybe there is a chance for me. I'm a really crappy programmer no matter what the language (VB, Java, C++, Prolog). I mean, after "Hello World" I'm pretty much lost. So maybe there is hope.
************************************************ ***
Being bitter is drinking poison and hoping someone else will die
Look up in the sky... its a bird... its a plane, no its Take-a-quote-out-of-context guy!
DrLunch.com The site that tells you what's for lunch!
But I don't necessarily agree with him.
He never once considers (as far as I could tell in my admittedly hasty reading) speed issues for more advanced languages. There are plenty of fancy languages out there, but C/C++ is still the choice for power without sacraficing speed.
That said, I think more powerful constructs are very important, and I've seen several of them implemented in C++, with very positive effects.
Persistance can make managing of not only game objects (i.e. saved games become trivial) but resources very simple, since a resource file (standard formats like TGA or DXF, or your own internal formats) are just simple methods of persisting data. If your data all lives on disk in its "dead" state, it's very easy to organize and bring up what you want out of a database. It's possible to build very intelligent tools, too -- for example, developing the art and changing the game constants on top of a database that detects when you change something and loads it into the running game. Again, I've seen this system implemented in C++.
Along those lines, tools will become increasingly important as games get more complex. If you're going to run a massively-multiplayer RPG on the internet (à la Ultima Online, Everquest, etc) you need to have a crew of people there continously creating new art, models, and code, and they need to have an efficient way of doing it. Metadata about the objects in your game can let older chunks of code learn about and manipulate these objects as they are added. You can also do a lot of this in C++; the framework may be painful but once implemented there's no reason for it to be hard to use.
....
This is all well and good, but I still see a fundamental disconnect between language designers and practical programmers. Language designers are seeking elegant representations for cases that are complex in current practical languages (i.e. the mythical everpresent C/C++), but they aren't usually building "real" programs (the kind of programs you use every day) in them. There are other languages that are very practical, such as Python, or practical in theory, such as Java, but they're not particularly appropriate for games -- they're ungodly slow.
Perhaps it is time for a new language that balances hopefully a cleaner organization than C++ (perhaps dropping or at least heavily restructuring some of the more hopeless features like crazy dynamic casts and this chimaerical exception handling) but maintains the speed inherent in the language. It seems to me that game programmers are largely using a fairly safe subset of C++ anyhow; the representation changes in the language should make it easier to do the things we can now do with difficulty in C++, not make the impossible difficult. After all, that seems to be what Stroustrup was doing when he first wrote the first versions of C++ back in the early 80s.
....
You don't have to agree (except that Java sucks) and I'm not dissing PERL (but it will still never be a game language). Just my $0.02
I think he misses some points though. C++ wasn't supposed to provide binary compatibility, ANDF was the project of that era that was and it was amiserable failure. C++ biggest failure was that it didn't provide source compatibility between compilers and it still doesn't in some cases. Being tied to a compiler is far worse than being tied to one form of object code. I think C and C++ will be around for a very long time though, in proper hands both are very powerful tools. The trick is knowing how much of it to actually use.
The key, the big thing that's going on, the beautiful thing about now is variety. There isn't and never will be a silver bullet language. It's foolish to think so. A few years back, before java and the web made perl hip, it was C or C++, period. Now you have more options, to better pick the tool for your task. If you're aimed at linux, you've got tremendous options for picking a language to use, you can realistically write scheme or lisp and expect it to be runnable on a wide range of systems. That's the whole thing that was missed for so long, pick the tool for the job.
in the 1980's it was a big rift between Pascal, BASIC and C. Pascal and it's Wirthian siblings (Modula-2, Modula-3 (sort of), Oberon, and Ada) are beautiful languages that can excel at certain things, particularly large scale projects, but other factors have made them less popular. By the 1990s it was a joke to put Pascal on your resume because it almost had a negative connotation. Selection is coming back and that's the big thing.
thats the reason eiffel is not popular, its quite simple.
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.
http://slashdot.org/comments.pl?sid=00/01/25/15023 8&cid=290
:) == you think you are important == you think you are famous
:)
The short answer is coding at 3DR is more fun than:
people making bizarre generalizations about people they don't know
1. you said something == you think you are important
2. you want to talk (and ask about, and learn) about math/code / you say things I don't understand / you say things I can't discuss with == you think you are important / smart
3. you work at game companies that I "kind of" heard of before
4. you have "struggles" with being annoyed by "gender related things" / you are easily goaded or piqued into responding to dorky situations == you are not getting over yourself
Duke the game, boothbabe, zoomed angles, just pale by comparison.
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.
Your two statements contradict each other. If you refute the influence of the reporting of a particular phenomenon, you must also, by definition, refute the influence of language on thought. There is no such thing as a "direct visual experience"; it all passes through the brain. You're drawing a very artificial line between concrete and abstract thought.
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.
Quite a fishy introduction to languages, and a hacker's take of PLs. Not to dismiss anyway. There's a deep relationship between linguistics theories and PL, which haven't been uncovered.
;) )
;) An example is the Demeter project, an Adaptive Programming suite. As for Java, I have nothing to say, that's not the future. Or if it is, I don't wanna be a part of it. I'd rather become a peaceful fisher, in a beatiful seaside village.
;) we are talking about different syntax-es here: narrow syntax is so incapable (in my view), that it wouldn't account for a language of thought. Well, well, whatever. Even for a good implementation of "parametric polymorphism", the compiler architectures would have to take a quantum leap. So that's probably what we should try to do first (gcc won't help, gcc won't help, gcc won't help, gcc won't help, gcc won't help, kill the bison, gcc won't help...)
In that the PL is the LoT for programming, it's not a concise statement. But surely a better language *helps* you think better. This is arguably why language gets you live by successfully in a society, it will hinder you within common sense since lexicon is meant to capture an upper layer onthology of the world.
Then, the programming cliches and paradigms are to be known within the language. Indeed, "A library is a language, and vica versa", that is functionality and approach is what a PL grants, and so does a good library. That's why noone can be said to know ISO C++ without knowledge of standard library. Well, that might be the case for the author; the standard C++ is efficient, in fact it strikes a better balance of efficency / abstraction than ANSI C. Else, both are TM specifications, and are equivalent in power. Though not equivalent in expressive power as shown by advocates of object-calculus (including some of the current SIGPLAN chairmans I suppose
However, there is surely a next generation of programming languages. But that might lie further ahead than mere parametric polymorphism, though it is definitely the next thing to exploit. Perhaps Ada9x will take over our lives; ahh, if only it weren't that complex. As the prospective author of a new programming language, I'd see that his claims on the completeness of object models are doubtful. The thing is, it is not clear whether this is the correct or the complete model which we employ. In particular, any system which *allows* side effects is undesirable, also the current systems do not seem to be very orthogonal. Too restricted for a free exploration of possibilities, most language features are glue-ware, and bad imitations of Algol6x, Simula and Smaltalk. Only Lisp and Prolog, still are original, but neither are good for general purpose programming (flames, I can take them). Still, OO is the way to go, and C++ makes it realizable.
One possibility, of course, an exact implementation of pattern languages. (I'm not allowed to go into details
Another note would be related to compiler/interpreter technology. For a next generation of PLs, a next generation of somewhat "smart" compilers will be required. In fact, I'd envision that the compiler/interpreter sits at the heart of the system. The operating system, and all other applications share the same language subsystem... That is my vision, of course, and Java has no place in this vision! So I don't dream of a JavaOS, which would surely be a terrible thing to taste. Also, this has nothing to do with the Chomskyan tradition, no autonomy of syntax or nothing... I don't think that it's the syntax that makes things intelligent or creative, it is surely the machine's operation, and "programme" in that sense, which would have to be described by an expressive language that's all... Or okay
Comments?
--exa--
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?
It does compile (and run), and the Duke.Actor inherits the fields from the Unreal.Actor class. The purpose of the main() is to show that all the fields in Unreal.Actor can be accessed via the extended Duke.Actor class.
I'm a number, not a free man!
Maybe it's a cantonese thing? Who knows. Keep posting, CY.
Maybe it's a cantonese thing? Who knows.
Keep posting, CY.
what?! have you done any benchmarking with http://smalleiffel.loria.fr/ ? it's *fast*, *much* faster than any Java JIT. I haven't checked it against gcj, but I'll bet it's not far off.
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.
This is more nonsense propaganda by the PC Manufacturer/Microsoft coalition. Using false benchmarks and bogus statistics, they attempt to claim that lame PC cards outperform real SGI hardware.
You obviously don't know jack about graphics, PC or SGI.
Apologies for the empty post. Hopefully someone will moderate it into oblivion.
Reading this article it really struck me how much he's ignoring. He waxes eloquent about parametric polymorphism, but ignores the languages that do the best job on it (primarily functional). He also spends a lot of time asking for features that (at least mostly) exist in well-known, and well-used languages, that even have open source implementations. My particular example is Squeak (http://www.squeak.org), an open source Smalltalk implementation. There are others, and lots of them have been mentioned
Let's see about his wishlist
an open world so that source and binaries don't need to be changed to use new types. Check. The reference source of generic libraries for things like collections. Sorted list was written once 20 years ago and re-used for all types ever since.
function references bound to objects. Check. Blocks, aka closures. Incredibly powerful, and around for years in languages like LISP and Smalltalk.
higher order functions. Check. Basically the same thing.
simple, natural syntax. Check. His specific example was the APL-like ability to use + on collections. That's something they recently added to Squeak, without having to change anything fundamental in the system
polymorphic types with bounds, constraints, and proper variance relationships fo parameters. He doesn't talk about this in the rest of the article, and I don't really know what it means, so I can't comment.
introspection. The development environment is written in itself. You can introspect anything any which way you want.
built-in security, preferably enforced by the compiler. That's missing, partly because it's pretty hard to combine compile-time security with rich introspection and simple syntax. Security is supposed to get in the way
binary portability. Check. Runs on practically anything, including handhelds.
It even copied that garbage collection idea from Java.
Perhaps the languages of the future just require people to notice what's already there.
"This isn't to say that someone wouldn't be able to thing something like 'Big Brother is ungood', that would be something that would be inherently a silly and nonsensical idea to a party member ... The person would only be able to think in vague ideas" --Appendix to 1984(emphasis mine)
Sorry, that's a paraphrase, I loaned my copy of '84 to someone just yesterday. But you'll notice that Orwell didn't say that crime think would be impossible, only that it would impossible to communicate
Amber Yuan (--ell7)
"and dear god does this website suck now." -- CmdrTaco
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
Object Pascal achieves what you request.
;)
- It removes the little used features and arcane characters.
- Has excellent, easy to use, _reliable_ exception handling.
- Has *strong* typing for improved productivity.
- Compiles quickly to code of comparable quality to C++.
Unfortunately the language has been hijacked by Borland/Inprise with it's proprietary (but excellent) implementation. Also no sane programmer would use Pascal because it makes your code easy to read and of course, as far as jobs are concerned, obsurity = security
Let the holy war commence...
Come, my brother, we must join ranks and revive the wonder that is Forth! Today, the TI-85. Tomorrow, THE WORLD!!!! I mean seriously... Ok so you have to write in reverse Polish notation... It's so darn COOL tho... It makes you truly *understand* what is going on under the hood... It's so *powerful*, and yet so incredibly *simple*... We'll show them all. ;)
The streets shall flow with the blood of the Guberminky.
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...
Yes, he dissed lisp. Typical ignorance of a mainstream programmer (BTW most LISPs are not strictly FPLs). He also seems to believe the OO gospel from Meyer, GOF, the three amigos and many others. Most of the OO "truths" like "OO offers better reusability" can only be understood in the narrow context of mainstream languages. The marketing clauses have been stated so many times that most people accept them as the truth. Using objects (mainstreamly) forces people to think at a coarser level of abstraction in terms of who tells who to do what. This actually works very well, but the marketing has taken it way out of proportion and nowadays this seems be accepted as the only way to do it. For some applications using a different mindset like streams of data transformed by computational nodes might be more appropriate. It actually doesn't matter as long as it is efficient in modeling the domain and easy to implement in a programming language. It should also be noted that the very concept of object is not defined properly.
The very thing he is talking about, basically building abstractions to express the domain, is at the very root of LISP culture and has been for a long time. In the LISP world this is usually referred to as "building the language toward the problem".
This is actually what most OO people are doing. They are implementing classes that are domain abstractions and then expressing the solution in the formalized language of domain concepts they just built. Often they have to resort to patterns, because of the deficiencies of the language. The patterns don't usually have a meaning in the problem domain, but are only formalized hacks to get around a problem in the language. Some of the problems are caused by the dominant message-passing model of OO and implementation in static languages. This is not to say that patterns are bad, on the contrary, they are very important when developing in a language that needs them or when they actually have a meaning in the problem domain.
The LISP approach to this problem is not to bend around the problem, but to build the suitable constructs into the language to express the solution. Knowing the beauty of the language it is sad that it seems to be doomed to remain the language of the future indefinitely. Maybe this is because the people don't see the language from the parens.
A while ago, Tim Sweeney made a small game, which had a level editor in it. It was called ZZT, and had a built-in programming language (called ZZT-OOP), it spawned a few clones, and gathered a massive underground community.
-FweE-
Yeah, but those allocators won't save you at the point-of-failure:
memset(ptr,NULL,n);
They only kick in when:
- Memory is freed
- If you hit a guard page (if your OS supports it and you've put that into place with your heap allocator)
Why not just take away the ability to tweak memory like that? Besides performance numbers, what benefits are there for accessing memory directly (unless you're writing device drivers).The only thing I can think of is taking advantage of OS specific operations (like memory-mapped files and completion ports in NT).
-Chris
Ok, Crash, this is the last straw. Every piece of writing I ever read of yours has at least 50% of its content describing how great you are. Christ! Would you do us all a favor and shut-the-hell-up?!?! You are NOT special because you are a female. You are NOT special because you are a coder. You are NOT special because you are a female coder.
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...
What a great article! There's a lot to get through there, so I thought I'd add a bit of extra info about one bit I know well.
Tim mentions how much more clear it is to use direct assignment (A=B+C) for all types (including lists) than having to worry about the details of the specific classes. This issue is part of the study of generic programming. This is generally quite easy to do with functional languages (e.g. have a look at some Mathematica programs to see what I mean).
A lot of effort is going into making this available in C++, with a particularly success being achieved by the STL. The STL gets over the problem of speed through using templates, which (as Tim mentions) are dealt with at compile time rather than run time. Although Tim apparently has no time for templates, they certainly achieve good results in the STL.
Those of you with their thinking hats on will be wondering "but what happens if I write A=B+C+D?". The STL would create two loops and two memory copies, since it thinks of it as ((B+C)+D). Some very interesting work to avoid this problem is being implemented in class libraries such as POOMA and Blitz++ which implement the fiendishly clever concept of expression templates to actually create and traverse a parse tree of the expression at compile time. Of course, this can lead to very long compilation times. An amazing side effect of this approach is that if you never actually use a value in A (having assigned B+C to it), then it will never get evaluated (e.g. the classes use 'lazy evaluation').
If you're interested in trying out some of these ideas in a strongly typed language, it's worth looking at C++. You'll need a good compiler though--if you're using GCC make sure it's the latest version, or for better results still try KAI C++. If you're a complete newcomer try out a functional language--I particularly recommend Mathematica, although you can use the functional concepts in Python (e.g. Map()) and Perl to make a start.
But he blew it dismissing lisp and its derivatives early in the conversation. Most of the features that he wants have been explored in such languages to a much greater degree than anywhere else. The lisp languages lost the race a while back but I think we are in for a bit of a resurgence from scheme. Most folks don't even realize that compiled lisp out of the better envirionments is faster than java, nearly as fast as C.
The basic notion that language determines or limits thought in programming is crystal clear to anyone who has stretched the boundary of a few languages very often. The limitations of existhing languages are also obvious to those who push the boundaries looking for more expressive power and elegance.
The real question is not whether we need better languages and tools. The real question is what sort of process will really give them to us and make their use ubiquitous. The language/tools market is typically a hard place to build a successful business, especially to connect with early funding. This is one place where I believe Open Source is probably the only way the tools will be ubiquitous enough and evolve fast enough. Proprietary attempts have largely failed in this area. Anyone ever notice that many of our everyday programming tools haven't really changed or improved very much in nearly two decades? And no, it is not because they are so wonderful as they are.
I do like the virtual class concept and I've run into plenty of cases where it would have been real handy.
Relatively transparent persistence can be added to any language for which sufficient metadata is either directly present in the runtime environment, is derivable from the compile time environment or is programmatically created by defining a routine per class that one wishes to have persistent instances of. I've have built many such things and am working on a refinement that will soon be open-sourced. More to come. Building persistence into the language only solves part of the problem and only for users of that language and a particular form of data storage (generally). Actually there are a set of common problems that are data source type, vendor and language independent that should be and can be addressed. Specific language and database plugins can then be added to this central core as needed. An in-language "persistence solution" typically does not touch complex object graph persistence where objects must be reachable along multiple paths and not just relative to a single root. Nor do such approaches deal with object and object/relational concerns such as transactions, concurrency, queries, distributed data sources, schema evolution and so on. But as I said, more on this subject later.
Is it Open Source?
I is stupid and fatty!!!!
Haha!!!
-------------------------
"I shake the Devil's hand all the time!! He's my personal bitch!"
- They Might Be Losers
I love that quote. Where's it from? Mind if I "license" it? [grin]
Game Over Man! --Aliens
Would have been interesting to see an answer. You're pointing fingers (with justification I'd say) at techie/game sites for propogating gender-divisive stories/issues, but your company is probably the worst as far as propogating gender stereotypes and "gender divisiveness" in the games industry today. From the way 3DRs owners present their image publically, it seems the issue is a little deeper than marketing.
It seems like you're worsening/continuing the attitude that you're so miffed about. The games industry isn't going to respect women coders until it respects women, period. If you think sites like gamespy are going to interview a female who coded a game that stereotypes/arguably degrades women and NOT be focused gender related questions, you're drawing lines that don't fit. Don't get me wrong, I think you're rant was right on, but it seems to me you might consider your role in the situation a bit more before you start pointing fingers everywhere else. Perhaps you have a good answer for all this, but it seems like you're stuck in a Paradox to me.
Finally - ever read threads on these boards related to Quake/Id/Carmack? "Oh Carmack thinks he's so smart because he took some algorithms developed in the 80s and made a game. Whoopie". Your rant implied you were worthy of a long technical discussion that gamespy should have done. Do that, someone will take it as ego puffing, and you get bash. Point out whatever reason you got dissed (valid or not) and someone will dismiss it and bash you. It doesn't matter who you are or where you work. Welcome to virtually anonymous communcation, it's nothing to worry about.
Good luck!
*eat at joes*
All I can say is that this better be a joke.
-------- "All I want in life's a little bit of love to take the pain away" --Spiritualized
show us the code or get out of the way... everyone has their great ideas for a great new language... let's see you implement yours.
Do not make blanket statements like that with out explaining your reasoning.
---
I wear pants.
These dated languages are simply no longer needed for powerful game development. C level performance and high level power is available NOW in several languages, Eiffel for one.
Ridding ourselves of these dated languages will also increase developer productivity and also the quality and reliability of software.
And remember, when working at a higher level, the program has no ties whatsoever to a specific OS.
Rather than putting forth huge amounts of effort in making a program cross-platform compatible, developers should use a language that does it for them.
on another tip, the validity of compiled languages in most application scenarios is diminishing. With the web becoming the user interface of choice almost all programming will be done in script, on the client and the server. The only place for compiled code will be for the OS and server type applications. This doesn't leave much room for a barrage of compiled languages.
-Jon
this is my sig.
Python will do everything Sweeny dreams about, and makes it seem quite natural. And it's here today. So there.
Hmm... Java is dynamically typed, and most of the time it isn't "really, truly" compiled. (Unless you count compiling for a VM as "really, truly").
Lots of the stuff does rely on compiler technology advancing, but it really is. One important issue is that stronger type systems are required to make compilers much better than they already are (every C/C++ compiler I know of "black-boxes" function calls completely, meaning that since there's too much link-time voodoo, they can't optimize into function calls at all). In other words, compiler technology is not likely to improve much unless we abandon current paradigms in favor of statically-typed languages.
- Tom 7
I'm glad Tim wrote this, I certainly began thinking about items mentioned.
... it must be good.
I started with Object Oriented programing by buying a NeXT and beating my head against the ideas of Objective-C. I learned the hard way that C=A+B is what I wanted, but then it wasn't possible...
Or was it. Unlike C++, Objective-C, a strange descendent of Smalltalk and C, did allow me to write a set of very clean abstarctions to do exactly C=A+B, where A,B&C are arrays.
Why? Objective-C is run-time bound, therefore programs can be extended after compilation.
Today, Apple plays down the impact of Objective-C in their Mac OS X documentation. It was the crown jewel at NeXT and the reason Carmack and Co built Doom on the platform. The programming tools were better (and most copied) then anywhere.
And yes, there was a penalty in speed for all this "late binding" and abstraction. On my 25Mhz NeXT, that was alright for the sheer simplicity of design.
With the proliferation of Mhz today, you would think that we could just adopt the same things and run with it? Naw, Tim also pointed out a strong failure of the programming community: Once a language is deemed "unpopular", no matter what it is giid for, it is discarded.
That's fine, maybe PR is all that a language really needed. Heck, if you can write UT or Quake3 with it
-Chris
In terms of looks, XiangHua is my favorite, followed by Yoshimitsu
My engine code doesn't have memset, my friend.
:)
I call C_Zero_Memory.
(I also have C_Fill_Memory for those necessary moments.)
So, yes, it can assert at C_Zero_Memory, on the stack, at the point of failure.
BTW. C stands for Common as in Common functions. It does not stand for Corrinne.
P.S. A corollary is C_Zero_Memory is (and can be)platform optimized. Internally for windows, C_Zero_Memory calls ZeroMemory.
To quote his article:
> To add a new variable to the actor class, you
> wouldn't edit our code, you'd simply subclass
> the entire engine, with a declaration like
> "class DukeNukemEngine extends UnrealEngine".
> Then you'd extend the DukeNukemEngine.Actor
> class and add your new variable to the
> subclass -- just the variable, no cutting and
> pasting of other code.
Now, unless I'm missing something, the following
Java 1.2 code does what he wants:
Unreal.java
-----------
public class Unreal {
String world = null;
public class Actor {
int strength;
int dexterity;
int health;
}
public class Walls {
int x;
int y;
}
Unreal() {
world = "Unreal World";
}
Unreal(String name) {
world = name;
}
}
Duke.java
---------
public class Duke extends Unreal {
public class Actor extends Unreal.Actor {
int magic;
}
Actor myActor;
Duke(String name) {
world = "Duke "+name;
myActor = new Actor();
myActor.magic = 4;
myActor.strength = 6;
}
public static void
main(String args[]) {
Duke game = new Duke("Dead World");
System.out.println(game.world);
System.out.println(game.myActor.strength);
System.out.println(game.myActor.magic);
}
}
The Duke class has added a magic field to the
Actor subclass, and can use all of the fields
in the Unreal.Actor subclass as well.
I'm a number, not a free man!
Have you ever heard of Yogi Berra, an American baseball player?
Not at all, but I don't know a lot of French soccer player so I am less likely to know American Baseball players.
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?
I can't think of any funny way to translate it but I think that "It's deja vu all over again!" is better said in English,I can't find a good way to translate it back in French, maybe "C'est du deja vu deja vu" (it's a "deja vu" deja vu) but this isn't really funny
By the way, I think that what made me think of using "deja vu" instead of "already seen" was Neo in Matrix, when he talks about the black cat, I probably encountered it b4 but hadn't integrated in the English I used at the time.
"The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." Bill Gates,
XiangHua followed by Yoshimitsu?????
When I picked my Soul Caliber character, I based it soley on how scantily clad the character was, not by the overall looks.
My personal favorite is Sophitia. She rocks! She can easily defeat that Rubberized chicken thing they call Voldo, and that stupid overgrown bluebelly lizard thing they call LizardMan.
# apt-get install smalleiffel ... 37192 files and directories currently installed.) .../smalleiffel_1.8.0.78-3_i386.deb) ... ...
Reading Package Lists... Done
Building Dependency Tree... Done
The following NEW packages will be installed:
smalleiffel
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 1143kB of archives. After unpacking 5130kB will be used.
Get:1 http://http.us.debian.org potato/main smalleiffel 1.8.0.78-3 [1143kB]
Fetched 1143kB in 6s (164kB/s)
Selecting previously deselected package smalleiffel.
(Reading database
Unpacking smalleiffel (from
Setting up smalleiffel (1.8.0.78-3)
Building HTML index of the Eiffel class library...
... HTML build completed
Whoops, there goes Debian again, giving out proprietary software.
"Beware of Lizardman....." :: echos into the distance ::
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
There are some terms that cannot be satisfactorily expressed in another language. For example, there is no satisfactory spanish substitiution for the word "loomed". There are spanish words meaning "to stand over", but none that conveys the same sense of menace as the word loomed.
I've noticed this trend of 1st posters being loggen in rather than AC. What is that all about? Make moderators waste 2 points instead of 1 to make it -1?
(way offtopic, better mark it down quick!)
/.why log in to first post? Anyone can claim to
/. moron? as i've exponded many times, AC are not necessarily anonymous nor cowards. I simply refuse to register as a /. moron.
/. is that at first they are unix weenies in their idiosyncratic funny ways but as the site becomes popular, stupid & halfassed attitudes become the mores and norms of the vast majority of /. readers who are just another sophomoric teenager waiting to get out of school. All opinions but no content.
/.be an AC...but there is only one TheWall (or
/. melvin, or dammitjim, Meept!, etc.). What
/. claim to fame do you have if your name
/. isnt on it?
just another
The thing about
Xah
xah@best.com
http://www.best.com/~xah
You should take note of how recently the number zero and the equals (and plus etc.) symbols were invented, and what the Greek/Arabic mathematicians did without them.
John
John_Chalisque
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?
When programming, I try to keep 50% of my concentration on the job at hand, 25% on how I'm doing it, 12.5% on how I'm thinking about how I'm doing it, 6.25% on how I'm thinking about how I'm thinking about... etc. ad nauseam.
The article is great though, really bringing some of that horrible Computer Science stuff out into the open. I think most programmers who haven't been formally trained eventually start banging their heads against brick walls. But their problems are often well-served by these sorts of accessible and pragmagic articles on theory.
Though I agree wholeheartedly with what Tim says, it's perfectly possible to sit at your keyboard wondering about your approach to a program, deciding that a C++ / Apache / carrier pigeon hybrid solution might involve a bodge and there must be a better way of doing things. And then you've got a deadline looming (or a life to be getting on with), panic, write the whole thing in COBOL and have done with it.
Matthew @ Bytemark Hosting
Many of the things that Tim Sweeney is after appear in Delphi.
// good old procedure variable
// Delphi
:= class(tList) with tFrog;
:= tFrog;
:one of ContainerType);
I use Delphi as my language of choice. Many people challange me on this because most of the things I do isn't in the area of bulding guis from drag and drop controls. But Although that is a cool feature of Delphi it is not the reason I use it over C++. The language underneath is extremely well constructed.
Apart from the object orientation of the pacsal there are key new features.
there is Published Properties for Run time type information which is just plain cool. But other things are things like...
var
Wibble : Procedure;
Gleep : procedure of object;
enhancement.
Procedures of object let you call methods of instances of objects.
next
type
tFrogClass = Class of tFrog;
var
AFrog : tFrogClass
AFrog is a variable that refers to a type of object, not an instance of an object.
Parametric polymorphism is not supported yet. But the bones of the creature are there.
Imagine
MyFrogList:=tList.Create(tFrog);
The parameter of the contructor would be of type tFrogClass;
(Note - much of what is below is not actually in Delphi, I'm just pointing out possibilities for logical extentions)
There are two possible ways to do Parametric Polymorphism (PP from now). You could create a type staticly
or Dynamicly.
Staticly would be akin to C templates. I think Dynamically would be More flexable, essentially Static PP would provide more compiler errors. Dynamic would have to throw exceptions.
Static PP would accept things like
type
tFroglist
var
MyFrogList : tFroglist;
begin
MyFrogList:=tFrogList.Create;
Here a new type is constructed which would enable the compiler to do type checking on all items bing passed to and from that type.
Dynamic PP would accept things like
var
MyFrogList : tlist;
MyCar : tCar;
begin
MyFrogList:=tList.Create(tFrog);
MyFrogList.Add(MyCar);
Here a cetain degree of Compiler type checking could be done. A smart compiler should be able to spot that a tCar cannot be passed to the list.
The comiler would have to track all assignments to MyFrogList to ensure that no other objects of type list have been assigned. Tricky but not impossible.
Run time type checking would still have to be used if there is any chance of the compile time type checking missing anything.
Run time Type Checking would Cerainly be needed for something like the following
type
tClassOfAnything : class of tObject;
var
MyFrogList : tlist;
ListType : tClassOfAnything;
begin
ListType
MyFrogList:=tList.Create(ListType);
At the moment only one extra language feature would be required to support PP. A few more to make it nice.
You need to control function return types to be the class of the object used.
for instance Function tList.GetItem(index : integer) one of ContainerType;
This gets interesting because the return type is the contents of a variable of type Class of something.
Essentially the construct 'One of thing' is a type of checked type.
Similarly you could also provide the system for a parameter
Procedure tList.Add(NewItem
I'm relativly certain that something like this will happen eventually. Borland have always extended their pascal to support new language features.
I'm also quite confident that what they do to add this functionality will be much better than any design I could come up with.
-- That which does not kill us has made its last mistake.
People are not bees.
But let's just agree to disagree, OK?
This language has recently been turned into a GNU open source project, and solves the worst of the problems of languages such as Java, C++, and even Eiffel. (I consider Sather to be a nicer language than Eiffel.) The problem is that it needs to be brought up to production quality, in terms of tools and compiler availability. Volunteers? Cheers, Ken the Anonymous Coward
An Octane/MXE card leaves a TNT for dead.
:o)
I'd use IRIX 6.5, if I had the chance, every day over anything else. It scales very well, if done properly. An R12000 makes a PIII look like pretty pathetic. I think any rational person knows that.
*puke* SGI and Sun will be in the business for a while yet. Pixar, for one. All those lovely Sun machines
SGI is dead? Sorry, their ccNUMA architecture will mean that they are very relevant and will outperform virtually anyone in supercomputing performance. Their SV1 series, well, second to none.
http://www.sgi.com/octane/techspecs.html if you need some reminding of the octane performance. It walks all over any shitty peeeceeeeee.
imho, SGI has done more for high end graphics than pretty much anyone else.
**This message was brought to you by the letters N, T and the number 666**
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.
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.
>
Nobody says implementing a generic list class or sorter in Java is difficult -- but implementing these in a strict language with parametric types (ie ML) is much, much, easier, and much, much more elegant (ie, no downcasting or runtime tag checks!). I suggest trying out an advanced language before making claims like this -- Tim is defininitely on the right track.
- Tom 7
Taki is the super number one best player. She throw opponent out of arena many times. She is followed only by Sophia, who uses cheating sword move. Remove half of health, one hit. All others no good. -any cwrd
I thought 'gratis' was a part of the English language. I Danish (and other languages) it means "something you don't have to pay for". Well, and least it's what it means today. I'm not sure about what it's orignal meaning was. Perhaps you should borrow this word for the GNU.
Taki is my 2nd favorite. She used to be my 1st favorite until I truly learned Voldo.
Sophia is a "good" fighter in a cheesy cheaty way.
Taki is so darn fast that sometimes it feels cheaty with her too. She can get her attacks out faster than all the other characters.
I am half serious. It is factual I have blocked all news. Reading chick troll news, and reading subsequent ignorant generalizations, get me riled up for no good end.
:)
I know as well as a lot of AC posters that my writing does not and cannot change the world to a more enlightened place. Maybe my code can, after I spend more time on it.
If I keep getting indignant, I'd turn into a John Katz.
Lisp has had a compiler since the MacLisp Days Of Yore(tm), circa the 1960s. Most modern Lisp implementations are purely compiled. That's right: "Just In Time" and "Incremental" compilation have been features in most Lisp products for at least the past twenty(!) years.
Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, DEATH, SubGenius, mhm21x16
I'm proud of my Northern Tibetian Heritage
it was a joke
Amber Yuan (--ell7)
"and dear god does this website suck now." -- CmdrTaco
computers won't change the world into "a more enlightened place". they just homogonize culture and push down the masses, making them yet another tool for the man. games are the worst, because they fool the tools into thinking 'hey, i'm having fun', but in reality they just waste time. if you want to change the world, coding isn't the answer.
join the peace corps and make a real difference.
Tim, you seem to like adding arrays, so I think you should write his next engine in Matlab. Your program would be crossplatform then!
It would be a huge mistake for developers to use perl for a large project. Why?
Firstly, it has hideous syntax. Most perl programs are so difficult to read, you will see a comment for every line of code. It also was not even designed to be an OO language, it's OO aspects were hacked on, just as with Basic and C++. Perl has its uses. It can manipulate text very well and is good for short programs, but not software.
As for languages that could be useful for what Tim describes, how about Eiffel? It is language very big on performance and robustness. There are also very good development environments for it and several very important projects have been comleted using it. Here is a link describing its many benefits and comparing it to C++:
http://www.elj.com/eiffel/bm/
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
You know, this was one of the more interesting and thought-provoking essays I've read in a while. Even if you ignore his questionable assumptions, you're left with some interesting ideas about "what's coming next".
It's a pity that that the replies I'm reading right now are mostly "My language rules. Your language sucks."
Oh sorry, I just remembered that I was reading Slashdot. Carry on with your silly language flames....
He does seem somewhat less than willing to look at the advantages of functional languages in the article (maybe he doesn't realize Haskell is a functional language?).
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?)
as for practical aspects, game development requires performance, and now that you can compile LISP (and other languages), the only excuse for not using LISP is willful ignorance.
an interesting thing to note is that circuits are exactly like functions, and many EDA tools are written using some LISP dialect. the future of programming involves conflating hardware and software design into "design", and realizing an implementation on the fly (what's the difference between a scripting language and reconfigurable hardware?).
in conclusion, i think the author misses the point entirely.
--thi
You're okay.
Everyone else needs work.
I find it amusing the fanaticism involved around programming languages. Usually I program in the "modular" form (non-OOP), but it seems the OOP crowd has somehow missed out. They seem to think you can't write efficient, easy to maintain systems without OOP to hold your hand through the process.
I write complex billing systems for large corporations using COBOL and don't believe OOP would improve the process. The complexity involved with the OOP model outweighs the benefits, especially in regards to maintainability. Aren't subroutines that can be called from ANY module, essentially inheritance through modularity? In addition, this method doesn't have the code bloat associated with OOP. Why declare variables of type object (X), which could have 50 properties (subroutines), when all I need to reference are 10 of them? Simply call the 10 subroutines directly, from anywhere. The way I see it, OOP came about to try to force weak programmers to follow a structured approach. Which admittedly, the modular method is weak at enforcing. However, you can write some real crap using either.
I work with a Visual Basic group that interfaces with our system to work service orders from the service technician's trucks. They use "modern" tools and we use "dinosaur" mainframe tools. However, we still manage to finish before them most of the time, with fewer errors. Curious.
People give COBOL a bad rap, but for what it is used for, it would be hard to replace. I pity the company that embraced C/C++ as their batch processing language. COBOL is better suited for those tasks. It is also easier to maintain and more self-documenting than any other language.
My personal favorite language is Pascal or Object Pascal under Delphi. I would use it for any task. If you haven't already tried it, give it a look. It smokes C/C++ for readability and runs just as fast. Delphi also has all those nice OOP characteristics people like these days.
--Scott
--Scott 8-}
I've always believed that video games are the best programs that you can use to test the performance boundaries of your PC. Where the average spreadsheet application or word processor would run on almost any old system, it usually takes the top of the line powerhouse to run the newer, cutting-edge games of the time.
It's all about pushing the envelope. *grin*
The man is an MS whore, And I'm not just trolling here. He's constantly saying that DirectX is easier then OpenGL. Why? because Microsoft helped him port Unreal (written in Glide) and they had to pay people to rewrite the Glide code to GL. Sweeny didn't do any of the work himself.
Even more surprising are his opinions on the Microsoft Case. He has actually said "If Microsoft hadn't been allowed to integrate TCP/IP and Internet Explorer, there would be no Unreal Tournament". I understand the TCP/IP, but I don't see what having an embedded browser has to do with a game... Could be that Sweeney's just on crack though...
[ c h a d o k e r e ]
ReadThe ReflectionEngine, a cyberpunk style n
strong typing is for those with weak minds...
Amber Yuan (--ell7)
"and dear god does this website suck now." -- CmdrTaco
Been there, done that..check it out at:
http://www.planetquake.com/q2java
It's plenty fast, and does a whole slew of things that would be a real PITA to try and code in C (internationalization, security, dynamic loading of gamecode - so you can switch mods on-the-fly, and lots more).
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. How is creating games that require better hardware influencing anything in a good way? Should I be thanking bloated software makers for the Athlon?
My karma is already down to -4.
I've actually got nothing better to do right now. Work is sloooooooooooow.
**This message was brought to you by the letters N, T and the number 666**
packets may fly where they may, but why not just drop the runts before they enter the stack?
Makes more sense now .. sounds a bit like Smalltalk, my experience with which was that it was very slow.
I can't imagine that sort of thing not having so much overhead that you can't really write a game with it. But I guess part of his point is that hardware is getting faster and faster, and pretty soon I suppose game programmers (and in fact many other programmers) will want to use something like that.
can you tell me what the difference is between those who are prejudiced against what you believe, and your own prejudice against those you don't?
ROTFL!
Easy.
:) because to high noise to signal ratio) I continually give devil's advocate benefit of doubt.
:) )
The difference is that (despite the huge waste of my time
Though I do have to admit to my human frailty of "preferring society and companionship of intelligent men" by "my highly personal *prejudiced* standard of intelligence and insight."
(i.e., One man has full right to prefer bimbo over an ugly woman. I have full right to prefer social company of intelligent men by my narrow definitions.
I seldom assumes any flaming *idiot* as incapable of intelligent thought, just misguided and closing his mind to greater understanding and enjoyment.
oh yeah, programming languages is a S-W field if there ever was one. hey, to me, everything's starting to look like a hashref :)
Corinne's post explained one of the reasons that I have always disliked inheritance, and preferred flat C like modularization.
The other reason is that somehow OO concepts have remained too fancy to use in a constrained way, thus being a dangerous source of ill-handled unnecessary complexity in practice.
Here I'd like to point out my favourite environment: Bell Labs Plan 9 / Inferno. I think it was mostly the main architect of the system Rob Pike, who kept to the design principle, that OO the traditional way was mostly harmful.
Pike and friends made a radicallly simple design choice. The Limbo programming language used in Inferno did not have inheritance. The idea was to keep fine grained module dependencies within one conceptual framework: exported functions, types, ADT's and variables, much like in Modula-2 originally.
But they recognized the need to modify existing funtionality of larger scale functionality without changing existing code statically. So they invented this ingenious mechanism for OS level objects and inheritance: synthetic or procedural file hierarchies, per process name spaces and stacking of these objects to inherit each other in a cotrolled way.
So in Inferno and Plan 9 you can program your objects in any language that you want, be it OO or not, and then "stack" them dynamically, even distributed on the net, producing exactly the effect of inheritance.
Inheritance is a great mechanism when used with care and constrain, preferably between a few easily manageable high level concepts. It is bad, if it is used as an ubiquitous low level programming concept cluttering all your code with strange propagating dependencies.
Anssi Porttikivi / app@iki.fi
Yes, but does one have full right to prefer bimbo over "ugly woman" in a business sense when determining who should be hired? I don't know.
:)
I guess there is some room for the person/company's views on who would be the best fit for the position. If it was a position where appearances had an effect (ie: ratings/revenue) then good-looking/ugly would be an acceptable criteria, even if it is all in the eye of the beholder.
Same goes for intellectual criteria. Should a company be allowed to discriminate based on their "views" of intelligence? Intelligence is really not as easily defined as a lot of people seem to believe. Intelligence is fuzzy at best. Just like beauty.
Personal life is a different matter. People generally tend to use prejudice as a negative term for personal preferences that they do not agree with. Which sounds better?
A) I am prejudiced.
B) I have personal preferences./I have standards.
A significant part of the population (dare I say most?) will not admit to A but admit B. Those who openly admit to A get set upon as if they were a guest on Jerry Springer.
Of course, I'm probably preaching to the converted here.
AC
eh ... that's why I posted the question ... you put up your web site, but not your email. :)
I did your Java VM project on your web site.
> You would never write a game engine in Perl or Python.
;-), it's a company you are familiar with and a title you've almost certainly heard of.
Well, I can vouch that there is actually a major project in development that is using Python for all of its game logic. Not for the graphics engine, networking, and other performace-critical subsystems, of course, but the *game* itself is coded in Python.
Unfortunately I'm under NDA with said company, and I'm not 100% certain that they would appreciate me revealing details. Just trust me
My understanding is that they are quite happy with Python. It's elegant and simple enough for designers to use, its performance is "good enough," and it's easy to integrate with C/C++. Custom scripting languages are always incredibly labor intensive and rarely live up to expectations, Perl is unreadable gobbledygook, C and C++ are too low-level and too powerful (aka dangerous). Java would probably be a close contender, but still I'd say Python is easier to learn and use. I don't know anything about Eiffel nor whether they considered it as an alternative.
While working on graphics engines for other projects, I've used Python to code testbeds, benchmarks, and simulations. The speed of the compiled bytecode is more than adequate for such high-level control.
why would someone choose your position over another one? is there some logical argument that I could follow that would show me that your position is superior? what makes "the social company of intelligent men" better than running in the company of wolves, are they the same thing, or are you presenting your subjective tastes as flamebait?
Um... you're doing it again. You state:
Neither speaking, nor verbal nor abstract reasoning, was necessary.
Obviously, by reporting the color (even in the form used by B-K), the respondents have to classify it in some way. That is thought, and at least in some aspects abstract (whatever definition you want to give that term). How can it not be? There's no direct link between your retinas and your writing hand that allows it to do something like what was required in the B-K tests, without first undergoing some form of reasoning.
The B-K tests reached the conclusion that there's a gradual development from a two-color system to a three-color, etc., and that that development is generally the same across all cultures - but it doesn't mean that there's no thought involved in the process. It just means that the thought processes reached similar conclusions in each case.
Sorry, but it's true - sad as it may be. Remember 99% of computer users are not on Linux
std::valarray C,A,B; C = A+B; or am I whacked outa my mind?
I thought I saw lisp being used somewhere in that game..
;). Of course if you go for lossy programming you could get better 'compression' but lose substantial control.
Anyway, abstraction for the sake of abstraction is missing the main point.
What most programmers do is make decisions on what decisions the computer is going to make.
If you want really want things easier, then the idea is to reduce the number of trivial or rare decisions encountered, and make it "obvious", this is a tall task as there are so many situations and they keep changing.
But in a way a programming language is a type of "decision decompresser". You change one input bit and lots of different output bits get changed depending on your input bits.
I doubt there will ever be a "best decompresser", it's just like compression software.
Dreaming of a do everything command is not very useful. Sure you could have compression software where 1 = complete works of Shakespeare and 0 = "Hello World".
What you could aim for is the 'deflate/zip' of the programming language world. e.g. zip is very good for most text documents, executables, clip art. And not too terrible for photos
There will always be a degree of work as long as you make decisions.
Cheerio,
Link.
As much as I love my well-worn copy of "The C Programming Language", I'm not sure that I could write a compiler based on it.
The real question is not how many pages the K&R book has, but how many pages are in the ANSI C standard. I suspect that it's quite a bit longer.
This was a good technical article with some interesting ideas, and I'm proud to see it on Slashdot.
I think the reason that functional languages are left out of the evaluation is that they are "research", and as such tend to have more of the features that will be in "The Language Of The Future", which will be whatever is worthy to finally replace C/C++ as the development language of the future, and do a good job.
I've been learning Scheme lately, and the design of the language encourages a lot of flexibility and reuse. Since the data types are numbers and symbols (which are atoms), and lists, (and S-expressions and functions...) all you can really do is recursive list manipulation. But that turns out to be a lot. (and you can build code from data, too) Some of these concepts will take off and be successful, and others won't, but it will be interesting to see what the future holds...
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
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.
You stated in your post that you felt that java was good 'in theory' but that for practical purposes it was simply to slow. While this was true when java first came out, the speed has been icreasing quite a bit. There are other things that make java a bit slow, but I think realisticaly It could be used in a game. Carmak was even considering using it for plug-in moduals, but decided to implement his own dynamicaly compiled language (based on ansi-c) beacuse he wanted more control of the VM.
[ c h a d o k e r e ]
ReadThe ReflectionEngine, a cyberpunk style n
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
If they don't properly understand the --- I'm going to upgrade it to a theory --- then that means that they don't understand it, not that it's wrong.
Human thought happens in various modes. Some of it is visual modeling, some of it is evaluations along the pleasure-pain axis, some of it is kinetic/goinometric simulations (useful esp. in judging, e.g., how heavy something is). And some of it is formal reasoning/verbal communication. This last form is highly restricted by the language(s) of the person who is thinking. The prior modes of thought are not so restricted. All of the thinking can be used in analogical modes, which basically means using one mode of thought to draw links between sections of models in another mode of thought.
But each mode of thought has some special area in which it is supreme. The mode of formal reasoning/verbal communication has it's areas of unique applicability, and adjacent (note-a spatial / visual metaphor) areas of thought in which it is better than any of the other modes. These areas are profoundly influenced by the language(s) that are spoken/understood. And in these areas the Whorf Theory is valid.
N.B.: This doesn't mean that there is no way around the obstruction. It merely means that such thoughts take longer to form, and so will be thought less often. And communicated less often. And will not be available in emergency situations (i.e., under time pressure).
This is perfectly analogous to programming languages. Different languages are adapted to different tasks. Practically all of them are complete languages, but one would, perhaps, not write a compiler in Visual Basic. One would, perhaps, prefer Fortran for Numerical Analysis (part of that is history...it's already been done, so all I need to do is link to previously written code, and then slap in a few extra features). One might prefer to write a GUI interface in TCL or Java rather than in assembler. etc.
I think we've pushed this "anyone can grow up to be president" thing too far.
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.
most consumer video cards are designed to get the max fps in games, lets see that tnt2 against a permedia3 card in 3dsmax. Of course quake will run slower on an expensive SGI, they didn't design an expensive computer for games, they designed it to do real work. 3d modelling, realtime simulations, not q3.
Only the State obtains its revenue by coercion. - Murray Rothbard
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.
Why do people log in and First Post rather than AC the first post? No its not to waste moderators points, I can care less what the moderators do with them. Ever since the karma thing I've had to wade through the muck anyways. I used to browse -1 but sometimes I'd browse normal with a highlight threshold of +2, now with karma many people are +2 for no reason, causing their message to slow down my download time and making me click links to hear someone do a me too.
Anywho I'm babbling here. To the point, why log in to first post? Anyone can claim to be an AC...but there is only one TheWall (or melvin, or dammitjim, Meept!, etc.). What claim to fame do you have if your name isnt on it?
// 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"
Adden:
If one believes
lack of a female virtual game character in one game causes or deepens sexism
one game's inclusion of a virtual female game character improves one's feminism
then one may as well believe Doom causes Columbine.
class Renderer {
public:
virtual Texture * loadTexture(const char * name, blah blah blah);
};
class Texture {
public:
virtual ~Texture() {}
virtual void makeCurrent()=0;
};
and implementing the linking back behind the scenes for each one, or getting fancy and making a couple of templates used to bui ld boilerplate links. (I seem to recall that being used in the FSM example in C++ Gems) I.E. if you're too lazy to write linkin g code for each new implementation (not to mention want to avoid repetitive strain injury and bugs from duplicated code you can then go ahead and write a couple of templates like
template <class Baseclass, class Renderer> class TextureTemplate : public Baseclass {
private:
Renderer * m_renderer;
public:
TextureTemplate(Renderer & rend, const char * name, blah blah blah) : m_ren derer(&rend), Baseclass(name,blah,blah,blah) { }
~TextureTemplate() {
m_renderer->unr egisterTexture(this);
}
void makeCurrent() {
m_renderer->mak eCurrent(this);
}
};
template <class Baseclass, class TextureBase> class RendererTemplate : public Baseclass {
public:
typedef TextureTemplate<TextureBase> MyTexture;
Texture * loadTexture(const char * name, blah blah blah) {
return new MyTexture(this,name, blah blah blah)
}
};
then for each class you want to use the public interface for and templated implementations of the behind the scenes ties you ca n do something like
class GLRendererImpl : public Renderer {
... do gl texture stuff here ...
public: void makeCurrent(GLTextureImpl & texture) {
}
};
class GLTextureImpl : public Texture {
public: GLTextureImpl(const char * name, blah blah blah) {
load up texture using opengl...
}
virtual ~GLTextureImpl() {}
};
typedef TextureTemplate<GLTextureImpl> GLTexture;
typedef RendererTemplate<GLRendererImpl> GLRenderer;
the templates are initially a fair chunk of work, and the pattern density of the above code is pretty dense, but the approach c an be amazingly versatile and cuts down considerably on duplicated code, note that the derived classes only have to focus on their specific implementation, the generalities are taken care of by the template implementations and no typecasting is required anywhere in the system, so there is no worries about accidentally passing say a Directx7Texture object to the GlideRenderer.
The gains don't really start to show until you've got 5-6 implementations in place however.
All of the above code has been slapped together off the cuff and is probably laden with errors and formatting problems from try ing to type it into a slashdot comment box so try to follow my intent vs. my syntax.
P.S. Formatting this was a BITCH, is there a reason why Slashdot doesn't allow the tag? I.E. kept munging my & type chars back into real chars so i had to switch browsers, paste back and forth to vi to regexp things into html-munged form. Hrmmf.
Sanity is a sandbox. I prefer the swings.
typedef TextureTemplate<GLTextureImpl, GLRendererImpl> GLTexture;
typedef RendererTemplate<GLRendererImpl, GLTextureImpl> GLRenderer;
thats why i get for writing this stuff off the top of my head.
Sanity is a sandbox. I prefer the swings.
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.
For example, some GUI's were developed in C, even though I call them an advancement of C++. I'm just being practical here.
That's an odd statement. The first commercial GUI, the Mac OS was written in Pascal, as was windows (initially, some win32 functions even use the PASCAL calling thing, IIRC). The Xerox parc stuff was done in Smalltalk
OOP gives us an easy way to deal with GUIs, but They are not dependant in any way on it.
[ c h a d o k e r e ]
ReadThe ReflectionEngine, a cyberpunk style n
Word is a pig because of feature and code bloat, not becase abstraction is slow or bloated.
Abstraction will always be a little slower (and that amount may vary tremendously based upon your circumstances).
However, processor speeds double every 18 months. Programmer productivity MAY have doubled in the last 25 YEARS.
Conclusion? Abstraction makes things easier for the programmer, so the programmer can work better magic. YAY ABSTRACT!!!!
JAAC
Just Another Anonymous Coward
Looks like I amalgamated 2 cool Namco games into one. Voldo is in Soul Caliber. Xiao-Yu is in Tekken.
:) ) cuz Ivy's "mid" range attacks suck. It is distance attack. Or close attack. Then there are these huge gaps in distances where she has no fighting wherewithal.
So the analogy would be I'd rather play Voldo than Ivy (who looks cool
Voldo can slink into and out of a lot of situations.
Honestly, with all the obscure languages fliting about the place am I really the only old timer here who simply adores APL?
Using the specific example of A+B APL has to be the clear winner because it's the exact kind of problem that it's optimizied for.
Why would I want to use anything else?
Going way OT :)
... :)
That's why the 1st module I ever write and put in a new project is memory and heap allocators, full of overrun magic numbers, underrun magic numbers, freed data tokens.
You do some memset like this
big giant assertions go boom.
The closest thing to what is being described in terms of a non-experimental/non-academic language seems to me to be either Haskell or BETA. Haskell is free and available for Linux, Beta is also free and comes with an extensive development environment (called Mjølner) and it is also available for Linux (yay!). Both of these langauges are very interesting.
Most of the other systems that implement new ideas are experimental and not available AFAIK, but papers describing them are available.
Some good papers to look at are:
These are good starting points. For more places to look see my list of language bookmarks , especially under people & projects (or specific languages).
Excuse me... I seem to think that Crash Bandicoot is a game.... and that Autocad is an application... I must be mistaken... Sorry for my stupidity.