There are only two people in the world that should be allowed to create languages: Brian Kernighan and Dennis Ritchie. And repeat smart things like not treating arrays as first-class entities?
Honestly, C is full of design errors. Understandable back then, but nowadays these guys would either repeat their mistakes, or design something entirely different than C.
I am actually surprised somebody defends the creators of C. I was expecting a defense of the Lisp creators, or Haskell, etc.
I mean 1,000 lines of C++ and C# compared... I'd expect to see fewer errors in the C# and less severe errors when I find them.
Depends on your skills. C# is a safer environment, but C++ has immensely more expressive power. With modern and well-coded C++, these 1,000 lines may equal to 10-20,000 lines of C#/Java. Unfortunately, the ugly C++ syntax and its C cruft make unlocking the true advantages of C++ a black art.
A trivial example is the STL. Java/C# containers don't come even close to the STL's power. Go further and look at Boost.MPL/Fusion/Proto, and you'll see stuff you simply cannot do with Java/C#.
Well. If it were by me, Lisp would be king. But its not a perfect world:)
All inexperienced developers think that it will be a "necessary first step in clearing out years of cruft", until they actually try it. Then they realise that the "years of cruft" often had good reasons for being there and solving the problems the "cruft" solved is actually extremely hard and not always elegant. And how much code qualifies for this? I have rewritten several old libraries with modern C++, and gained a lot. Not because it has shiny new language toys, but because the old stuff was extremely hard to debug, maintain, let alone extend. (Also, they partly relied on stuff that gcc4 no longer ignores, and internally used global variables, making it useless for multithreading.)
It is true that a rewrite is usually not worth the effort, but not because the code is so clever. This "cleverness" often turns out to be one endless heap of ugly hacks. Its the sheer volume of the rewrite that makes it prohibitive; add to it the efforts for testing, and you often have a net loss, not to mention even crappier code, because that rewrite was late already, so everybody rushes it, and the developers only partly understand the old code etc.
So, in short: usually you have to live with old crappy code because there are is no net gain in rewriting it. Living with it usually is the lesser pain. But old code being excellent is a rare reason.
nVidia doesn't do the APIs for their cards. Wrong. GPGPU absolutely demands specialized APIs - forget D3D and OGL for it. These two don't even guarantee any floating point precision, which is no big deal for games, but deadly for GPGPU tasks.
I keep hearing this, and it is still nonsense. The space program is damn CHEAP compared to our other spendings. Just check out the military funds for one hell of a money sink. Americans even spend more money for fast food.
Cut the funds for weapons research. You get hundreds of billions easily this way. By destroying NASA, you get maybe 10-20, and lose one of the few federal departments that make some sense.
That's not to say that NASA is without problems. NASA is a slug, inefficient, aging, and a good example of bureaucracy gone haywire. Still, closing it would have very little, if any, impact on those "world problems". Half of these problems originate from ideological madness; you can throw any amount of money at them, they won't go away.
But I agree on something else: put the manned spaceflight on the backburner, don't rush things. Concentrate on materials research, especially nanotubes, their properties in zero-G environment, and especially how well they shield cosmic radiation.
I'd transfer the trillions that are wasted on the US wars to research of new energy sources. This solves lots of problems on earth (dependence of oil, which has very real political problems, climate issues) AND helps the space program as well, because the no.1 issue with space exploration IS energy. If we had the energy source, we COULD lift ships from the ground as big as the Nimitz.
the idea of using the NASA budget for other projects is flawed. NASA's budget is tiny. And, at least NASA inspires and produces useful technology from time to time. Argue against the military budget instead, which is already in the trillions. But leave NASA alone.
Don't touch the space program. Cut military funds. Even 1% of the military budget is more than you could ever get from destroying and forbidding space exploration.
Space exploration isn't the huge money sink. The military is. The Iraq war alone costs over 20 times more than NASA's budget. So go and argue against senseless wars and DoD contracts for yet more deadly weapons.
the billions going into space would be better spent stopping world war 3 down here. I'd rather spend the TRILLIONS that go into the wars and the weapons R&D. When will people learn that NASA isn't even in the top 100 of the US' tax money sinks?
That *could* be heavily optimized with lookup tables, but there wouldn't be much point. Nowadays, lookup tables for log and sqrt are unwise. The CPU has instructions for this, and lookup tables just trash the cache. Random numbers *can* be reasonable as a LUT, especially pseudorandom stuff like Perlin Noise. But your average random() function does not belong in a LUT either.
Until we have a perfect lie detector, and 24/7 survellience of every man, woman, and child, then there's gonna be innocent people going to jail, because there's always going to be an overzealous cop, a DA with a chip on his shoulder, a victim who fingers the wrong guy, a mistaken eyewitness... Be very careful - some politicians might take this as an excuse for stripping away all remaining rights to privacy.
Honestly, I'd rather live in a country where I may get accused of a crime I didn't commit than one where I have zero freedom. Come to think of it, wasn't this freedom the very heart of the US' attractiveness compared to the USSR in the Cold War?
I agree. The shading can be done very, very well nowadays, but once things move, the illusion is dispelled. In Half-Life 2, I was instantly amazed by the movement of the Strider and the Hunter aliens. It made them believable, more than just a bunch of triangles. A level with multiple striders and hunters attacking, alongside these flying synths and the soldiers is very immersive because the behavior of the acting entities is so believable.
Maybe among all these top 10 games lists, its time for a top 10 game animations one...
It is impossible to target their hardware when developing AAA titles, however. It would require enormous scaling. If these abundant GMAs would be equal to low-budget ATI/nVidia cards, things would be different. But even a 6200 gives GMAs a run for their money.
WHEN (and only when) the technology is fast enough for real time recursive ray tracing, it will be the end of rasterization in 3D applications. Oh yes, the brute force solution. It will be a very long while until it is fully obsolete. Expect hybrids to stay for a long time. An example: many people claim terrain culling methods to be fully obsolete nowadays. Then they try to render really large terrains...
Also, given that hybrids are a no-brainer, I bet both pure raytracers and rasterizers will be extinct in games.
Cache coherency problems can be fixed by making an enormous cache, or simply making the RAM itself so damn fast it doesn't matter anymore. Ehrm.... got any other wishes?! You do realize that this would be a revolution and might not be possible? One of the reasons why the cache is fast is that the signal propagation delay can be much lower due to the proximity of the cache to the cpu. In other words, there will always be a cache. As for an enormous cache: cache mem is very expensive, is likely to be because cache performance doesnt stand still (read: it will always use more expensive special hardware), and huge caches have issues with cache misses.
Adaptive subdivision of pixels for antialiasing is not exactly a first year student problem but not enormously difficult either. I didn't say its enormously difficult, just not nearly as trivial as with rasterization.
Honestly, I want to see the technology blow right past raytracing and go straight to radiosity 1. Radiosity is not the ultimate. Just try doing specular stuff with radiosity. 2. Algorithmic complexity will always come back to haunt you. O(nÂ) will always be worse than O(n), unless you have small scenes. So you have your geforce19000 and can render... ONE room with realtime radiosity! Nice! Somebody else fakes it and renders an entire city. Guess what will be chosen for games. 3. You could have said path tracing or photon mapping at least.
Finally, these people don't particularly favor raytracing simply because it does not pay off for games. Games usually don't feature fully shiny scenes, games are expected to run at interactive framerates. In, say, 5 years, entirely new (and demanding) effects are en vogue; if raytracing steals too much time, it will be dropped, its results faked. This is what the "old men" do all the time in their games: fake. In the offline world, things are wildly different, so don't compare them.
Primary rays have no advantage whatsoever over rasterization. Secondary rays, now THIS is where it gets interesting. Primary rays can be done fully with rasterization, in fact rasterization is nothing more than a clever first-ray optimization. Therefore, a hybrid is the way to go.
Your "precious scan conversion" and "those algorithms" blubb shows serious lack of knowledge about the actual algorithms. I suggest you do some in-depth studies of them before posting again. You fail to mention issues like cache coherency (given practically for free in rasterization, while hard to achieve in a raytracer). Antialias is also not trivial, unless you go brute force and sample multiple rays per pixel. In rasterization, everybody uses multisampling, a very simple and efficient algorithm (not without drawbacks though, but the performance benefits usually outweigh them).
Oh, before you mention lighting: lighting models are independent of the rendering method. Global Illumination has _nothing_ to do with raytracing as the frame rendering method.
So... without fancy secondary effects, where does this leave us? With the same output a rasterizer can give me, only with much better performance (largely thanks to the cache and missing intersection tests) and just as easy. Reflections, now this is hard with a rasterizer, but thats why a hybrid is wise; use rasterization by default, and secondary rays for those parts of the scene where these effects are visible.
People quickly get blended by the apparent elegance of raytracing. Just try to raytrace fast.. it won't remain elegant for long. And just like many papers, at some point you'll use rasterization, because it IS faster in special cases, which usually make up 60-70% of the scene (opaque, (un)lit surfaces).
Surprises are actually language-independent. Any complex construction may show up "surprising" behaviour. In C++, the syntax sometimes makes it even worse; typos may result in valid code (like an unintended invocation of the comma operator) that crashes at run-time.
I'm not saying C++ is the zenith of programming. I am saying, however, that there is absolutely nothing that can replace its entire range. Subsets? Sure, Java and C# are subsets of C++' expressiveness. But the entire range? You have to glue several languages somehow, and this is awful and often very inefficient.
I think the future of programming languages (which is actually a blast from the past, like 90% of all programming "novelties") is actually present in C++ already, but in an ugly fashion: languages that adapt themselves in a metalayer to the problem. C++ can do this, although its a huge PITA because of the template syntax and error messages. Lisp is king there, but AFAIK cannot do this at compile-time. Python, too, can do this. Java and C# lose here. This is why many features that need to be built-in in Java/C# are often realized by writing a library in C++, Python, Lisp.
As of "by design", I fully reject "dumbing down by design". Java isn't a sane subset of C++, it threw away key advantages. Thanks to missing real generics, it is absolutely impossible to write truly generic stuff in Java. You could never ever write something like Adobe's GIL or Antigrain with the same efficiency. Example: two vector classes that both have 3 floats, xyz; they are identical, but thanks to missing true generics, I have to write glue code, or agree on a base class, which is very problematic. In C++, I don't NEED glue code at run-time; I may need some at compile-time, but it is optimized away. People keep shouting at the JIT compile stuff and forget important things like this. Well, hopefully Java 7, 8, whatever, will include them.
If you only NEED a very small subset of C++, and this subset happens to be the one Java covers, then yes, its ok.
But your point about featuris is invalid. In you opinion, powerful language = hard to write a compiler for & hard to program for. Untrue. C++ requires good programmers, this is true. But Java is the WRONG solution. Dumbing down a programming language is just plain wrong. Recast C++ into something sane, without throwing stuff like generic and metaprogramming out. I too have seen server-side code, and I agree that most C++ code there is unstable. Its also enormously crappy. However, using modern C++ with tr1, boost, asio etc. I can for example write a stable http server with a fraction of the amount of code necessary in a Java implementation while keeping everything sane and stable. However, this requires lots of skill. But once you are there, Java feels quite limitating.
My main problem with Java is that it forces every problem to be a nail so it can be beaten with the Java-OOP hammer (Java-OOP, since for example Objective-C has different OO). For business stuff, this may be fine. But physics simulations, finite element/volume calculations, meshing, etc. cannot be cast into one paradigm only - here is where C++'s multiparadigmatic nature shines.
To summarize: is C++ a suboptimal language? Yes. Is it bad to support multiple paradigms in one language? No. Python, Lisp, OCaml prove this. D is a much better C++ replacement attempt than Java while being relatively simple to code for. Unfortunately, its still immature. Time will tell what it becomes.
The C++ committee is off in template la-la land, putting in features that few will use and fewer still will use correctly. (Coming soon: "concepts"). Obviously, you didn't understand them, otherwise you would know that generic and template meta programming are C++'s true distinctive powers, not some cheap vtables, manual resource management, or C compatibility.
Before you start: Yes, I know you are a seasoned coder, and did lots of work. It is no excuse for not understanding the "template la-la land". You can argue against them all you want (you won't hear any disagreement about C++'s crappy template syntax from me for example), but please use some VALID arguments.
Yes, in an even match, Lisp vs. C++, Lisp would almost always win. I agree.
But in the real world, Lisp toolchains are a PITA compared to whats there for C++, especially regarding optimization (well, Scheme's Stalin is nice, but I suppose we are talking about Common Lisp here). Also, I've yet to see a Lisp that allows me to do bare metal coding and high-level stuff like the GP's in one source. It certainly is possible... but no one did it so far. Also, is compile-time generic programming possible in CL currently? Compile-time compiler checking or the like? A very strong argument for C++ is that this stuff is never done at runtime...
So maybe a slightly updated CL, with a much better toolchain, would be the ultimate.
Slashdot Mirror
Honestly, C is full of design errors. Understandable back then, but nowadays these guys would either repeat their mistakes, or design something entirely different than C.
I am actually surprised somebody defends the creators of C. I was expecting a defense of the Lisp creators, or Haskell, etc.
I mean 1,000 lines of C++ and C# compared... I'd expect to see fewer errors in the C# and less severe errors when I find them.
:)
Depends on your skills. C# is a safer environment, but C++ has immensely more expressive power. With modern and well-coded C++, these 1,000 lines may equal to 10-20,000 lines of C#/Java. Unfortunately, the ugly C++ syntax and its C cruft make unlocking the true advantages of C++ a black art.
A trivial example is the STL. Java/C# containers don't come even close to the STL's power. Go further and look at Boost.MPL/Fusion/Proto, and you'll see stuff you simply cannot do with Java/C#.
Well. If it were by me, Lisp would be king. But its not a perfect world
Extremely weak generics that do not really offer much. After using generic programming in other languages, Java/C# generics look like a sad joke.
Then you didn't understand Python.
Just look at pythonic code, and compare it with Basic. These two don't share anything.
It is true that a rewrite is usually not worth the effort, but not because the code is so clever. This "cleverness" often turns out to be one endless heap of ugly hacks. Its the sheer volume of the rewrite that makes it prohibitive; add to it the efforts for testing, and you often have a net loss, not to mention even crappier code, because that rewrite was late already, so everybody rushes it, and the developers only partly understand the old code etc.
So, in short: usually you have to live with old crappy code because there are is no net gain in rewriting it. Living with it usually is the lesser pain. But old code being excellent is a rare reason.
GPGPU absolutely demands specialized APIs - forget D3D and OGL for it. These two don't even guarantee any floating point precision, which is no big deal for games, but deadly for GPGPU tasks.
its just my handwriting.
I keep hearing this, and it is still nonsense. The space program is damn CHEAP compared to our other spendings. Just check out the military funds for one hell of a money sink. Americans even spend more money for fast food.
Cut the funds for weapons research. You get hundreds of billions easily this way. By destroying NASA, you get maybe 10-20, and lose one of the few federal departments that make some sense.
That's not to say that NASA is without problems. NASA is a slug, inefficient, aging, and a good example of bureaucracy gone haywire. Still, closing it would have very little, if any, impact on those "world problems". Half of these problems originate from ideological madness; you can throw any amount of money at them, they won't go away.
But I agree on something else: put the manned spaceflight on the backburner, don't rush things. Concentrate on materials research, especially nanotubes, their properties in zero-G environment, and especially how well they shield cosmic radiation.
I'd transfer the trillions that are wasted on the US wars to research of new energy sources. This solves lots of problems on earth (dependence of oil, which has very real political problems, climate issues) AND helps the space program as well, because the no.1 issue with space exploration IS energy. If we had the energy source, we COULD lift ships from the ground as big as the Nimitz.
And spending 400B on slaughtering people in Iraq is favorable, right?
Help the children with these billions, and leave space programs intact. At least NASA makes some sense.
As said countless times:
the idea of using the NASA budget for other projects is flawed. NASA's budget is tiny. And, at least NASA inspires and produces useful technology from time to time. Argue against the military budget instead, which is already in the trillions. But leave NASA alone.
Don't touch the space program. Cut military funds. Even 1% of the military budget is more than you could ever get from destroying and forbidding space exploration.
Space exploration isn't the huge money sink. The military is. The Iraq war alone costs over 20 times more than NASA's budget. So go and argue against senseless wars and DoD contracts for yet more deadly weapons.
It would be SO ironic if one had to use Wine in Cygwin to play older games in Vista without crashes...
Except that Javascript is much more powerful than Java can ever hope to be. It's the environment thats crappy, not the language.
Seriously, you should at least *understand* the languages before you talk nonsense.
Honestly, I'd rather live in a country where I may get accused of a crime I didn't commit than one where I have zero freedom. Come to think of it, wasn't this freedom the very heart of the US' attractiveness compared to the USSR in the Cold War?
I agree. The shading can be done very, very well nowadays, but once things move, the illusion is dispelled. In Half-Life 2, I was instantly amazed by the movement of the Strider and the Hunter aliens. It made them believable, more than just a bunch of triangles. A level with multiple striders and hunters attacking, alongside these flying synths and the soldiers is very immersive because the behavior of the acting entities is so believable.
Maybe among all these top 10 games lists, its time for a top 10 game animations one...
It is impossible to target their hardware when developing AAA titles, however. It would require enormous scaling. If these abundant GMAs would be equal to low-budget ATI/nVidia cards, things would be different. But even a 6200 gives GMAs a run for their money.
Also, given that hybrids are a no-brainer, I bet both pure raytracers and rasterizers will be extinct in games. Cache coherency problems can be fixed by making an enormous cache, or simply making the RAM itself so damn fast it doesn't matter anymore. Ehrm
2. Algorithmic complexity will always come back to haunt you. O(nÂ) will always be worse than O(n), unless you have small scenes. So you have your geforce19000 and can render
3. You could have said path tracing or photon mapping at least.
Finally, these people don't particularly favor raytracing simply because it does not pay off for games. Games usually don't feature fully shiny scenes, games are expected to run at interactive framerates. In, say, 5 years, entirely new (and demanding) effects are en vogue; if raytracing steals too much time, it will be dropped, its results faked. This is what the "old men" do all the time in their games: fake. In the offline world, things are wildly different, so don't compare them.
A superior rendering method because ... ?
.. it won't remain elegant for long. And just like many papers, at some point you'll use rasterization, because it IS faster in special cases, which usually make up 60-70% of the scene (opaque, (un)lit surfaces).
Primary rays have no advantage whatsoever over rasterization. Secondary rays, now THIS is where it gets interesting. Primary rays can be done fully with rasterization, in fact rasterization is nothing more than a clever first-ray optimization. Therefore, a hybrid is the way to go.
Your "precious scan conversion" and "those algorithms" blubb shows serious lack of knowledge about the actual algorithms. I suggest you do some in-depth studies of them before posting again. You fail to mention issues like cache coherency (given practically for free in rasterization, while hard to achieve in a raytracer). Antialias is also not trivial, unless you go brute force and sample multiple rays per pixel. In rasterization, everybody uses multisampling, a very simple and efficient algorithm (not without drawbacks though, but the performance benefits usually outweigh them).
Oh, before you mention lighting: lighting models are independent of the rendering method. Global Illumination has _nothing_ to do with raytracing as the frame rendering method.
So... without fancy secondary effects, where does this leave us? With the same output a rasterizer can give me, only with much better performance (largely thanks to the cache and missing intersection tests) and just as easy. Reflections, now this is hard with a rasterizer, but thats why a hybrid is wise; use rasterization by default, and secondary rays for those parts of the scene where these effects are visible.
People quickly get blended by the apparent elegance of raytracing. Just try to raytrace fast
Surprises are actually language-independent. Any complex construction may show up "surprising" behaviour. In C++, the syntax sometimes makes it even worse; typos may result in valid code (like an unintended invocation of the comma operator) that crashes at run-time.
I'm not saying C++ is the zenith of programming. I am saying, however, that there is absolutely nothing that can replace its entire range. Subsets? Sure, Java and C# are subsets of C++' expressiveness. But the entire range? You have to glue several languages somehow, and this is awful and often very inefficient.
I think the future of programming languages (which is actually a blast from the past, like 90% of all programming "novelties") is actually present in C++ already, but in an ugly fashion: languages that adapt themselves in a metalayer to the problem. C++ can do this, although its a huge PITA because of the template syntax and error messages. Lisp is king there, but AFAIK cannot do this at compile-time. Python, too, can do this. Java and C# lose here. This is why many features that need to be built-in in Java/C# are often realized by writing a library in C++, Python, Lisp.
As of "by design", I fully reject "dumbing down by design". Java isn't a sane subset of C++, it threw away key advantages. Thanks to missing real generics, it is absolutely impossible to write truly generic stuff in Java. You could never ever write something like Adobe's GIL or Antigrain with the same efficiency. Example: two vector classes that both have 3 floats, xyz; they are identical, but thanks to missing true generics, I have to write glue code, or agree on a base class, which is very problematic. In C++, I don't NEED glue code at run-time; I may need some at compile-time, but it is optimized away. People keep shouting at the JIT compile stuff and forget important things like this. Well, hopefully Java 7, 8, whatever, will include them.
If you only NEED a very small subset of C++, and this subset happens to be the one Java covers, then yes, its ok.
But your point about featuris is invalid. In you opinion, powerful language = hard to write a compiler for & hard to program for. Untrue. C++ requires good programmers, this is true. But Java is the WRONG solution. Dumbing down a programming language is just plain wrong. Recast C++ into something sane, without throwing stuff like generic and metaprogramming out. I too have seen server-side code, and I agree that most C++ code there is unstable. Its also enormously crappy. However, using modern C++ with tr1, boost, asio etc. I can for example write a stable http server with a fraction of the amount of code necessary in a Java implementation while keeping everything sane and stable. However, this requires lots of skill. But once you are there, Java feels quite limitating.
My main problem with Java is that it forces every problem to be a nail so it can be beaten with the Java-OOP hammer (Java-OOP, since for example Objective-C has different OO). For business stuff, this may be fine. But physics simulations, finite element/volume calculations, meshing, etc. cannot be cast into one paradigm only - here is where C++'s multiparadigmatic nature shines.
To summarize: is C++ a suboptimal language? Yes. Is it bad to support multiple paradigms in one language? No. Python, Lisp, OCaml prove this. D is a much better C++ replacement attempt than Java while being relatively simple to code for. Unfortunately, its still immature. Time will tell what it becomes.
Objective C, with improved C++ templates, hey THIS would rock. Count me in if this happens.
Before you start: Yes, I know you are a seasoned coder, and did lots of work. It is no excuse for not understanding the "template la-la land". You can argue against them all you want (you won't hear any disagreement about C++'s crappy template syntax from me for example), but please use some VALID arguments.
Yes, in an even match, Lisp vs. C++, Lisp would almost always win. I agree.
... but no one did it so far. Also, is compile-time generic programming possible in CL currently? Compile-time compiler checking or the like? A very strong argument for C++ is that this stuff is never done at runtime...
But in the real world, Lisp toolchains are a PITA compared to whats there for C++, especially regarding optimization (well, Scheme's Stalin is nice, but I suppose we are talking about Common Lisp here). Also, I've yet to see a Lisp that allows me to do bare metal coding and high-level stuff like the GP's in one source. It certainly is possible
So maybe a slightly updated CL, with a much better toolchain, would be the ultimate.