Skip to main content
GameDev.net gamedev.net
🔒 Locked

The future of programming...

Started by Sagar_Indurkhya Oct 14, 2004 at 10:25 AM 48 replies 4.6k views
Original Post
Sagar_Indurkhya
Sagar_Indurkhya
Ok. I know that the majority of the programmers at GDNET use C++, and C. But lets face it, 5-6 years from now, computers will be fast enough that we can allow to compromise speed for productivity. Things like Java and .NET will be considered fast enough, even for games. New languages will emerge. As I see it, after implemeting more realistic physics, the next thing will be AI. Unless we get some spectacular new development in this field, we won't be seeing any leap. So instead, games will have to have more levels, characters, etc. Also, longhorn will speed up all .NET applications, because .NET is essentially a part of the OS, so there is not as much over head. Here is my question: over the course of the next few years, what major changes will we see in terms of language syntax, standards, speed vs. productivity, ide's, and RAD? What about game development? How will the process change?
Extrarius
Extrarius
I predict that in the future, computers will be fast enough that people will feel free to waste billions of cycles for virtually no gain, but that even in those days there will be a need for people to write in low/medium-level languages like assembly and C++ because there will always be problems that require nondeterministic polynomial time (well, unless somebody proves otherwise =-).

Over the next few years, I predict that virtually nothing changes. Dot Net might become more popular (and other similar events might occur), but I don't predict a language revolution any time soon.
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
Sagar_Indurkhya
Sagar_Indurkhya
Yeah, but 10 years from now, I can super JIT optimize my program, something that would take 20-30 minutes right now, and have what, .001% speed compromise? Of course things like word will have shit loads of AI in them, and keyboards will be less and less used. I think programming languages will be designed so that we can speak it without saying "if" "open parentheses" ...
Miserable
Miserable
Quote:
Original post by Sagar_Indurkhya
Ok. I know that the majority of the programmers at GDNET use C++, and C. But lets face it, 5-6 years from now, computers will be fast enough that we can allow to compromise speed for productivity. Things like Java and .NET will be considered fast enough, even for games. New languages will emerge.

Plenty of people consider them fast enough as it is, and new languages emerge all the time.

Quote:
Original post by Extrarius
I predict that in the future, computers will be fast enough that people will feel free to waste billions of cycles for virtually no gain, but that even in those days there will be a need for people to write in low/medium-level languages like assembly and C++ because there will always be problems that require nondeterministic polynomial time (well, unless somebody proves otherwise =-).

Unless I misread you terribly (which, going on ~2 hours of sleep, I concede is possible), this is a property of the algorithms, not of the implementations; what do low-level languages have to do with it?
doynax
doynax
Computers are already fast enough to handle most applications in "modern" languages like Java and C#.

Besides people will always find new ways to send any super computer to a crawl. Therefore some of us will have to continue writing über optimized sphaghetti C, while the majority just think they need it.

However the reason most of us stick to C++ is just inertia.
felisandria
felisandria
The problem with the comments above is that when you say Longhorn is part of "the OS", you mean "Windows". Windows is not a realtime operating system which is necessary for an awful lot of stuff. So, I don't really see .NET taking over the planet, unless Linux, UNIX, etc, go the way of the dinosaur, which I don't consider very likely.

Java is a bit more likely, but so much is in C++ right now that it's more likely to be used in conjunction than instead of. Reusability is a big thing in industry, most of them are simply not going to have the cash, especially in this economy, to rewrite their entire source base in another language, nor are they likely to see a reason to. Yay inertia.

-fel
~ The opinions stated by this individual are the opinions of this individual and not the opinions of her company, any organization she might be part of, her parrot, or anyone else. ~
Washu
Washu
Quote:
Original post by felisandria
Java is a bit more likely, but so much is in C++ right now that it's more likely to be used in conjunction than instead of. Reusability is a big thing in industry, most of them are simply not going to have the cash, especially in this economy, to rewrite their entire source base in another language, nor are they likely to see a reason to. Yay inertia.

-fel

It's a good thing then that you can reuse a lot of your C++ source code with .Net. [grin] Especially with C++/CLI.
In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.
Oxyd
Oxyd
Whenever I see a sentence like "computers are/will be fast enough to ..." I feel like killing something innocent! [smile]

Yes - the computers will be faster, but I don't think, that's an excuse for being lazier (do less algorithm-level optimalizations). Java is already fast enough for things like theese and so are other languages. But Java is very often used in database programming or simillars, not games. There are so many languages, because every language has its purpose (C++ has evolved from C which is designed to be portable assembly, Java designed to be plattform-independent).

And for games - faster computer, means you can do more calculations within the same amount of time. So the number of effects will increase, the physics will be better and so on. The games will be still as fast (or slow) in means of frames rendered per second. The graphics will be nicer and nicer, the physics more and more acurate. And the rendered scene will still be so different from real world scenes, so the computer will still be too slow to be able to render real-world like looking scenes. (And if this had been possible once, the graphics would have moved to a higher level)

Oxyd
antareus
antareus
I recall hearing that the AI field has been stuck since the eighties. I also recall hearing a Knuth quote to the effect of, "any programming language attempting to mimic spoken language is doomed to failure."

Your future is now. GD.net just happens to house some very vocal C++ advocates. I expect future languages to continue to slowly pull features from functional languages and tout them as new and exciting. It certainly seems to be the dominant trend right now. (oooooo lambda functions in C# what a revolutionary concept!!)

I see games becoming something of a sport. You already see it with games like Counterstrike, but since most* games don't have a concept of virtual athleticism, you need fairly deep gameplay to keep people immersed for long periods of time. I am talking about skills that must be learned and practiced and are unfamiliar to the average FPS gamer. Skills that enhance the gameplay and shatter expectations.

Meanwhile, the MMOs will continue to afflict those with addictive personalities, but there won't be as many.

* Tribes has the best approximation of virtual athleticism I have seen.
--God has paid us the intolerable compliment of loving us, in the deepest, most tragic, most inexorable sense.- C.S. Lewis
Extrarius
Extrarius
Quote:
Original post by Miserable
[...]
Quote:
Original post by Extrarius
I predict that in the future, computers will be fast enough that people will feel free to waste billions of cycles for virtually no gain, but that even in those days there will be a need for people to write in low/medium-level languages like assembly and C++ because there will always be problems that require nondeterministic polynomial time (well, unless somebody proves otherwise =-).

Unless I misread you terribly (which, going on ~2 hours of sleep, I concede is possible), this is a property of the algorithms, not of the implementations; what do low-level languages have to do with it?
You are correct that algorithms determine the order of time, but that is only the 'number of steps' so to speak to complete the algorithm. If each step takes 0.1% longer in Java (for example), and you're doing trillions of them, it adds up to "using lower level languages to get that 0.1% speed increase can make a BIG difference in run time" =-)

Of course, that really applies to scientific programs more than anything else. We already have enough processing power to make great(as in fun, meaning good gameplay and potentially mediocre 2d graphics, sound, etc) games in any language that I know of.

Quote:
Original post by Sagar_Indurkhya
Yeah, but 10 years from now, I can super JIT optimize my program, something that would take 20-30 minutes right now, and have what, .001% speed compromise? Of course things like word will have shit loads of AI in them, and keyboards will be less and less used. I think programming languages will be designed so that we can speak it without saying "if" "open parentheses" ...
I don't see any huge increase in computing power over the next 10 years really. Sure we might have quad 4GHz machines as the default, but not everything can be made out of paralell building blocks. I guess as far as java goes, you could have 3 processors compiling various classes and 1 processor actually running the code, but I wouldn't really count that as 'faster' unless the binary is cached so you only have to compile it once. I'd hate to have to wait 5 minutes each time I want to start up notepad just because it was written in a language where the program had to be recompiled on each run.
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
Sagar_Indurkhya
Sagar_Indurkhya
Yeah, but no matter how much you optimize, the eye cannot process images faster than ~25 per second? So getting a game to render at 300 fps isn't very important. Also, obviously assembler and C/C++ will never really go away, just like people still use fortran, but for almost everything short of an earth simulation, you are going to use some language that is more productive. I mean, once longhorn is out, there won't be such thing as: "hey, you have to go download an 80mb file to use my 5mb program!" Also, I expect far less people will use dialup. Most apps like word, etc, will just be run of your home server.
As per AI, I don't think we are going to really do any serious AI work, where we actually are able to create a sentient thing, until quantum computers come, and they are at least 20 years away.
Codemonger
Codemonger
I don't think things will change that drastically in the next 5 years. Im' still using a mouse/keyboard and monitor. Same as 10/15 years ago. I remeber reading that Speech Recognition was the next best thing years ago and how faster computers will allow it to be mainstream. I'm still waiting. While computers get faster, computers get more complex, and tend to also get slower because the requirements are higher. ie: next gen OS's might be 3D and require 10 times more memory and processing power just to run the OS, and blazing fast video cards. Things don't always get faster in that sense. I'm still waiting for the average Joe around here that programs games to pump out Quake 3 in their spare time. Computers are 10x faster when Quake 3 came out, so why can't everybody write Quake 3 now ? Well the bar has risen again and technology has taken a turn. Things that get faster also get slower and their is always a happy medium. Now the bar has been raised to FarCry (or whatever game), then it will be something else in 5 years. So yes, optimizations will always be around no matter what anyone may think.
-------------Become part of developing the specifications of a new language. Visit CodeBASIC.org
Extrarius
Extrarius
Quote:
Original post by Sagar_Indurkhya
Yeah, but no matter how much you optimize, the eye cannot process images faster than ~25 per second? [...]
The number is closer to 100(that therad has been done to death, use google to find one of the 50 or so versions on gamedev), and reguardless of how many FPS you lock to you can always use more power for the AI, physics, and other calculations beyond simply 'make pixel (X,Y) color (R,G,B)'.

Anyways, that isn't at all what I'm talking about (like I said we have plenty of power now for good games). Believe it or not, there are TONS of programs that need every cycle they can get (and will continue to do so until we have turing machines). No, you've probably never seen such a program, because they aren't typical consumer programs(games, business apps, etc).

I might be mistaken, but a good example of this is a VHDL->FPGA optimiznig program. For complex designs, it can take DAYS (literally) to optimize the speed of the circuit(as a FPGA layout) produced from VHDL, and the only reason it finishes so queckly is because the tools basically try several random configurations and then optimize each of those a little bit and then return the result of the best one. The resulting circuit is by no means 'fully optimized', because doing so could take a _REALLY_ long time (after all it must algebraically manipulate a TON of interdependant boolean algebra expressions to make the resulting FPGA connections either take as little room as possible or be as fast as possible while taking no more than X logic units, etc).

Quote:
Original post by Codemonger
[...]Things that get faster also get slower and their is always a happy medium.[...]
It isn't a happy medium, but it is a relatively stable one. I'd much prefer programs taking 1.5 times as long to come out so they can use 1/3 as much resources as they would have otherwise. Spending that extra time on optimization would make a huge difference in resources required for everything.
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
mikeman
mikeman
As for the "24 fps" thing:

I've heard it, but I know that I can tell the difference between a game running in 24 fps and another in 60 fps.

Maybe the eye can process 24 images per second, but these images contain information for 1/24 of a second. If an object moves in front of the eye, and we take one of those "images", I bet that the object will appeared blurred. Put all those images together, and you have smooth motion.

The computer-generated frames, however, hold information for only a singular moment. With 24 fps there, you won't have as smooth motion as 60 fps.

I can't really back it up, but that's just what I think.
Codemonger
Codemonger

Quote:

Quote:Original post by Codemonger
[...]Things that get faster also get slower and their is always a happy medium.[...]

It isn't a happy medium, but it is a relatively stable one. I'd much prefer programs taking 1.5 times as long to come out so they can use 1/3 as much resources as they would have otherwise. Spending that extra time on optimization would make a huge difference in resources required for everything.


I couldn't agree more, rapid development does come at a high cost, optimization and patience are definately a solution.

About the FPS thing, Why do people keep on saying that ? 24/30 FPS ... I'm sure their are technical reasons, but practical reasons ? everyone knows their is a difference between 30FPS/60FPS & 90FPS. So if everyone is visually aware of it then why the academic stand on 24 FPS ?

-------------Become part of developing the specifications of a new language. Visit CodeBASIC.org
iMalc
iMalc
Ahem, dood hellooooo...

The future is already here and we ARE using uber fast computers and Microsoft still make them seem as fast as computers from 5 years ago. All that extra processing power and MS still have to make US wait for the PC to finish refreshing a window for example - sheesh! (Prescott 2.8GHz)

The main thing that'll change is that games will be more about quality than speed as speed will be a given. You can see this happening to a huge extent already. Real-time raytracers aren't far away from becomming reality. Look out for them in the next 5 years. They'll still be using highly optimised C code in turn generated by a very good optimising compiler.
Sagar_Indurkhya
Sagar_Indurkhya
Ok. So I guess you can say that in the next 10 years we won't see any huge changes. What about in 20? I mean, once you near lifelike physics, and raytracers are the norm what next? I mean, you can only go so far with AI before you say, "Hey, I think I need real AI to make this look real." Once this point occurs, companies will start integrating more levels, running more things off scripts, etc, because computers will continue to get faster. They can say, hey, game quality isn't going to get much better for a while, so why not make our games in a more productive language, etc. We will be able to make more games, at the same awesome quality!
doynax
doynax
Quote:
Original post by Sagar_Indurkhya
Ok. So I guess you can say that in the next 10 years we won't see any huge changes. What about in 20? I mean, once you near lifelike physics, and raytracers are the norm what next?
Don't worry. We'll always find new ways to consume cpu cycles.
You can't make a perfect simulation of the universe, since you'd need a computer larger than the universe to run it.
So, no. There's no such thing as "fast enough" for games.
Sagar_Indurkhya
Sagar_Indurkhya
Ok. What about the way we program? I mean, surely in a little bit, we will have a version of C that you can speak, and it will have the exact same code, except when you read it, there aren't tons of parenthesis or something...
doynax
doynax
Quote:
Original post by Sagar_Indurkhya
Ok. What about the way we program? I mean, surely in a little bit, we will have a version of C that you can speak, and it will have the exact same code, except when you read it, there aren't tons of parenthesis or something...
Games will grow in complexity and new tools will be developed that to help make these tasks manageable.
But programming state of the art software is never going to get easy. Joel Spolsky pretty much sums it up in The Law of Leaky Abstractions.

Ever looked at Pascal? It's not very different from C expect that most language constructs are spelled out instead of using a compact operator notation. This is one of the "features" it gets bashed the most for.
Another big problem with natural languages is that they are far from unambigous.

[Edited by - doynax on October 15, 2004 5:21:33 AM]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.