Of course advancing space travel sounds good, we all grew up with science fiction. Also, the notion of "leaving the cradle" has a nice ring to it. But the main problem is the incentive. Why should we really go into space? The cradle argument is valid, but not a very big short-term motivator. Instead, I think harvesting resources is the real motivation. Getting materials from the asteroid belt alone would end resource problems pretty quickly. Running out of iridium, indium, platinum... ? These rocks are filled with it. Then there is also helium-3 on the moon, endless supply of hydrogen in the gas giants, solar radiation which can be harnessed much better from orbit (the old microwave beam idea),... The initial costs are enormous, but if there is a realistic reason why space travel should march on, it is this. Not the romantic picture of astronauts zipping through space.
Both this Slashdot story and TFA have a very misleading title. ONE MEP is thinking about this insane idea. It is not even in Parliament for discussion. Another MEP already vehemently spoke against it.
Come on, ideas like these pop up and fizz out all the time. I bet there are other MEPs thinking about imprisoning gay people, reinstating a theocracy, establishing re-education centers, idolizing Hitler and Stalin, and so on and so forth. That doesn't mean any of these wacky ideas come through. There are no indications that this one will.
Plus, it is not technically feasible, even with deep packet inspection. To connect the dots, to know who uploaded what where, is far from trivial, especially if the bad scary pedophile uses non-standard ways of transmitting this data. For example, what if he uses zip files? Also, there is encryption, which totally defeats this "logbox".
Not necessarily. Interfaces are a poor replacement for duck typing/structural typing. Using them this way is not nearly as flexible.
For instance, it is really nonsensical that I need to use a Comparable interface in Java just to be able to sort stuff. The right way is to define expressions that should be valid. This is possible at compile-time with C++, for instance, because the template metalanguage uses duck typing. Instead of requiring X to inherit from a specific base class, I can require the expression x <= y to be valid (x,y being instances of X).
This is in fact how things get sorted in C++. A sequence has to fulfill the EqualityComparable concept, meaning that x < y has to be valid with the type of the sequence elements. No base class necessary. In practice, this is very beneficial and much more flexible. Base classes have been described as "poor man's concepts", because this is how they are often used. Once one starts using concepts in C++, a lot of base classes simply vanish. Another language which implements something similar is Haskell with its typeclasses.
It is faster just to check for an interface of course. But it is by no means a perfect solution.
This is a technical detail. The relevant issue is that the metadata is always accessible from the outside. In the Java case, one has to explicitely downcast to access it. One has to know the type beforehand (in this case, its Integer). This is not necessary with dynamic typing.
Dynamic typing really shines with type traits, because then code can have conditionals based on properties of the type, like whether or not it is a number, an integer, a primitive type etc.
Type erasure strips away any metadata about the type. In Java, casting to Object is an example of type erasure. For example, when doing Integer i = new Integer(5); Object o = (Object)i; , there is no typesafe way to get access to the Integer methods & states. (Integer)o is not a type-safe cast.
As for dynamic typing, Wikipedia puts it well: "In dynamic typing, values have types but variables do not; that is, a variable can refer to a value of any type."
What you need to replicate dynamic typing in a very limited fashion in languages like C++ or Java is something like boost.any.
Dynamic typing is wonderful for scripting, but what you describe is not dynamic typing. Instead, it is type erasure. You essentially throw away type information and safety altogether, which is not the case with dynamic typing.
After submitting, I see that I have contradicted myself in one sentence. Replace "This means that you indeed have a sort-of untyped situation, where the concept is mere documentation" with "This means that you indeed have a not properly typed situation, where the concept is mere documentation". Because, as said, duck typing and typelessness are two different things.
You are wrong on several occasions. Templates are no preprocessor/macro system. Templates are turing complete, a proper duck-typed metalanguage. Duck typing does not equal "no type-safety". The problem you mention _is_ valid, but a fundamental issue in structural typing techniques. (Duck typing is a form of structural typing where the requirement-checking happens while it is being used, so to speak.) In terms of power, C++ templates _are_ comparable to Haskell typeclasses, for example - if used properly. (There are even papers comparing them.) Look up: generic programming, concepts, template metaprogramming. See the STL concept documentations for an example.
But you are right that the typing isn't enforced in the metalanguage properly. Concepts were supposed to do that, but were left out of the next revision of the language. This means that you indeed have a sort-of untyped situation, where the concept is mere documentation. You can manually replicate a concept check (which would equal the structual type checking), but this ain't trivial. However, compilation failures will happen if the concept isn't modeled properly. This is similar to the behavior in dynamic languages like Python, which use duck typing at runtime. If, say, you require something to have a foo() call, and it isn't present, the code will break when the foo() call is supposed to be made.
Also, I did not say that C# generics are template based. They aren't. They work differently, but do allow for expressions like the one I wrote, that is, without the unnecessary baggage that is an extra interface.
* first class functions, lambda, closures First class functions are primarily the realm of functional programming languages, not procedural ones. Lambda's, combined with ways to refer to them (C++ std::function, templates, auto) are a type of first class function. Closures provide an interesting alternative way to code some things, but seriously who really misses them in C/C++?
Have you been living under a rock? Just about every major language out there is implementing these features. Python, C#, C++, Ruby, Javascript among others. (Java doesn't, and it is sorely missed.) And, I do miss closures in C++. Right now I can think of several factory pattern implementations that would be greatly simplified if I could return closures instead of objects. Closures are objects are closures, sure but they do differ in practice.
* comprehensions Use a libary.
Good luck writing and/or finding one in C that doesn't end up requiring hundreds of lines for what can be done in at most 5 in other languages, like in Haskell.
* coroutines Use a library.
Forget it. Coroutines work completely against the abstract machine that C models. It is a different control flow, and screws with the stack. You *may* be able to do this with Assembler code inside, but this would necessarily apply to every coroutine you write. Not good.
* painless string handling Use a library.
No amount of C string libraries will be as convenient and easy to use as strings in other languages. C++ std::string is a good example. It is by far not the best out there, and still looks like heaven compared to the things that are usual in C. Guess why so many people use fixed char buffers for strings (and therefore cause potential buffer overflows): because proper string handling is a real PITA in C.
* module system To do what? You've listed namespaces and classes separately, so what's left that you can't do in C? Most C programmerss use paired.h/.c module definition/implementation pairs, and #ifndef/#define to allow module definitions to be blindly included.
The.h/.c stuff is exactly what has to go. Headers are used as interfaces 99,999% of the time, and are an ugly hack. I want _proper_ modules/packages, like the ones in Python, Ruby, C#, Java, ObjC. ONE file (.cpp). Intelligent dependency tracking. The pimpl idiom, the need for include guards, and having to manually find circular #includes are some examples why this obsolete cruft has to go, and is gone in every single major programming language except for C and C++.
* reflection C's a low level language. There is nothing to inspect. Feel free to build layers on top of it.
Oh come on. This is _exactly_ what I've said already: "Now, of course it is a valid point that these things do not necessarily belong in C. It is a system programming language, after all. But these features are very important for other domains, such as application development. Right tool for the right job, please. C is _not_ the shiny hammer, and not everything is a nail."
Of course C has evolved into C++ which has the useful items on your list, and is aquiring others (lambdas in c++0x).
As other posters and myself below already replied, using interfaces is just wrong. It adds unnecessary bloat, and uses the wrong type system. You want a _structured_ typing here, not a nominative one (which is what you get with interfaces). This is not about pseudo-reflection. Read below.
And guess what, in C#, C++, Python, Ruby, Javascript, Haskell, Ocaml etc. you do _not_ need an interface here. Using an interface in this case is just wrong, necessary in Java, but essentially wrong.
Generic programming requires structural, not nominative typing. The former does not care about the type's name, only about what it can do (for example, whether or not it provides a some_call member, or whether or not foo(x) would be valid if x is of that type). Nominative typing only cares about the name, it identifies the types by name. This is what you use with your interface.
In other words, the only requirement for the type should be that instance.some_call() should be a valid expression, and not that it inherits from an interface with name X.
No. K&R C lacks the following things: * first class functions, lambda, closures * comprehensions * coroutines * proper generics/templates (no, macros are _not_ a replacement) * painless string handling * module system * namespaces * reflection * support for common oop patterns and tools, like class definitions, dynamic dispatch etc. it has to be manually constructed, which is quite time consuming
Now, of course it is a valid point that these things do not necessarily belong in C. It is a system programming language, after all. But these features are very important for other domains, such as application development. Right tool for the right job, please. C is _not_ the shiny hammer, and not everything is a nail.
Then again, Java generics are an ugly hack that applies unnecessary type erasure, because internally, generics boil down to implicit down/upcasts (either from/to Object or a specified type in case of bound generics). C# generics and C++ templates are much more powerful and do NOT apply this type erasure. For example, try to do something like template < typename T > void foo(T t) { t.some_call(); } in Java, for _any_ type that fulfills one requirement: instance.some_call() should be a valid expression.
Well, defending against such an attack would be very hard, if not impossible, since the kinetic projectiles wouldn't be easy to spot. Add their extreme speed to this, and you better have excellent equipment that can find them quickly.
On the other hand, effective counterattacks are possible. Install killer satellites in orbit, armed with high-energy lasers or kinetic weapons of their own. Or, install ground-based lasers. This kind of armament is at least a decade away, but once its there, that ship you mention would not get away unscathed.
Actually, humans are way too diverse to be universally called noble or evil. Most people don't want to go out and whack some native tribes, they just want to be left alone. Also, in Avatar, its one corporation that acts greedy and evil, not the entire human race. Plus, their actions actually are illegal in that universe..
You do *not* need the full rendering equation in most scenes. Look at what today's games are capable of achieving, and it becomes evident. Also, raytracing does not fulfill the full rendering equation, path tracing does, which is a distinctively different algorithm.
And no, primary rays are *not* handled efficiently. As said before, raytracing offers no benefits here. However, implementing caching for rasterization is pretty trivial, since its all essentially just linear interpolation, whereas caching in raytracing is hard to pull off (which means that you lose a TON of performance with raytracing here, for no visual gain). Also, again: the geometry figure is pointless, for the aforementioned reasons.
Wrong. Rasterization is good enough for around 70-80% of all scenes. This O(n) figure is completely pointless, since games prefer high-resolution textures over high-resolution geometry. Carmack said it already: we do not want more triangles, we want prettier triangles.
Also, raytracing offers absolutely no benefits for primary ray cases. Secondary, indirect rays are the ones where the actual advantages come from.
The way to go is a hybrid. Use rasterization for the primary ray cases, and actual raytracing for the secondary ones.
If you want hardware-accelerated OpenGL without lots of headache in Linux, you want Nvidia. If you want hardware-accelerated OpenGL that supports more than OpenGL 1.4 (which is an ancient version), you want Nvidia.
ATI/AMD: driver headaches to no end. *Correct* OpenGL code causes kernel freezes, graphics glitches and so on. Intel: the older GMAs have terrible OpenGL support and are performance-wise in the 90s. The newest GMAs are OK for low-end stuff, but only because they are actually PowerVR SGX chips, and not made by Intel.
An earlier posting already hit the big misunderstanding with democracy in open source projects:
Democracy INSIDE a project is doomed to fail. There must be one leader who does the final decisions, otherwise you get design by committee.
Democracy ACROSS projects (more exactly, project versions, e.g. forks) is likely to succeed. If said leader does very unpopular and/or plain stupid decisions, the project gets forked. The majority thus "voted" against the decision. Case in point: Xfree vs. Xorg.
Yeah, right. And who will decide what "obscene" means? The religious right? See the Tipper Gore comment above.
With.xxx, expect it to become opt-in. And then people know you watch porn. They have it in written form. This would be even worse if you had to apply for accessing specific.xxx pages.
This is an illusion. The inevitable consequence of a language with very little features is a considerably increase in code complexity, precisely because the language is ill-equipped to express more complex problems.
Case in point: sorting algorithms, containers, callbacks.
The first one requires you to inherit from Comparable, which is a bone-headed move, because all that is _actually_ needed is just a valid comparison operation a < b (most other languages do it right).
The second one uses the hack called "homegenous generics" - in fact just a hidden set of casts from/to Object (or from/to the bound type in case of bound generics). Type erasure occurs, something like template < typename T > void foo(T t) { t.bar(); } becomes impossible (unless with bound generics, which are severely limited as well).
The third one is only really possible by using anonymous classes, which is again over-verbose and misses the point. Again, C# did it better by implementing delegates and allowing for first class functions, as all the other languages do.
Please note that your comparison with C is a bad one. Do not compare Java with C. Compare Java with C++ (proper, modern C++, not "C with classes"), C#, Haskell, Ruby, Python etc.
Slashdot Mirror
Looking at the rest of my comment, it should become obvious that I was not talking about near-term goals.
Of course advancing space travel sounds good, we all grew up with science fiction. Also, the notion of "leaving the cradle" has a nice ring to it. ... ? These rocks are filled with it. Then there is also helium-3 on the moon, endless supply of hydrogen in the gas giants, solar radiation which can be harnessed much better from orbit (the old microwave beam idea), ...
But the main problem is the incentive. Why should we really go into space? The cradle argument is valid, but not a very big short-term motivator.
Instead, I think harvesting resources is the real motivation. Getting materials from the asteroid belt alone would end resource problems pretty quickly. Running out of iridium, indium, platinum
The initial costs are enormous, but if there is a realistic reason why space travel should march on, it is this. Not the romantic picture of astronauts zipping through space.
Both this Slashdot story and TFA have a very misleading title. ONE MEP is thinking about this insane idea. It is not even in Parliament for discussion. Another MEP already vehemently spoke against it.
Come on, ideas like these pop up and fizz out all the time. I bet there are other MEPs thinking about imprisoning gay people, reinstating a theocracy, establishing re-education centers, idolizing Hitler and Stalin, and so on and so forth. That doesn't mean any of these wacky ideas come through. There are no indications that this one will.
Plus, it is not technically feasible, even with deep packet inspection. To connect the dots, to know who uploaded what where, is far from trivial, especially if the bad scary pedophile uses non-standard ways of transmitting this data. For example, what if he uses zip files? Also, there is encryption, which totally defeats this "logbox".
Not necessarily. Interfaces are a poor replacement for duck typing/structural typing. Using them this way is not nearly as flexible.
For instance, it is really nonsensical that I need to use a Comparable interface in Java just to be able to sort stuff. The right way is to define expressions that should be valid. This is possible at compile-time with C++, for instance, because the template metalanguage uses duck typing. Instead of requiring X to inherit from a specific base class, I can require the expression x <= y to be valid (x,y being instances of X).
This is in fact how things get sorted in C++. A sequence has to fulfill the EqualityComparable concept, meaning that x < y has to be valid with the type of the sequence elements. No base class necessary. In practice, this is very beneficial and much more flexible. Base classes have been described as "poor man's concepts", because this is how they are often used. Once one starts using concepts in C++, a lot of base classes simply vanish. Another language which implements something similar is Haskell with its typeclasses.
It is faster just to check for an interface of course. But it is by no means a perfect solution.
This is a technical detail. The relevant issue is that the metadata is always accessible from the outside. In the Java case, one has to explicitely downcast to access it. One has to know the type beforehand (in this case, its Integer). This is not necessary with dynamic typing.
Dynamic typing really shines with type traits, because then code can have conditionals based on properties of the type, like whether or not it is a number, an integer, a primitive type etc.
Type erasure strips away any metadata about the type. In Java, casting to Object is an example of type erasure. For example, when doing Integer i = new Integer(5); Object o = (Object)i; , there is no typesafe way to get access to the Integer methods & states. (Integer)o is not a type-safe cast.
As for dynamic typing, Wikipedia puts it well: "In dynamic typing, values have types but variables do not; that is, a variable can refer to a value of any type."
What you need to replicate dynamic typing in a very limited fashion in languages like C++ or Java is something like boost.any.
Dynamic typing is wonderful for scripting, but what you describe is not dynamic typing. Instead, it is type erasure. You essentially throw away type information and safety altogether, which is not the case with dynamic typing.
What if there is no "nearby system"?
After submitting, I see that I have contradicted myself in one sentence. Replace
"This means that you indeed have a sort-of untyped situation, where the concept is mere documentation"
with
"This means that you indeed have a not properly typed situation, where the concept is mere documentation". Because, as said, duck typing and typelessness are two different things.
You are wrong on several occasions. Templates are no preprocessor/macro system. Templates are turing complete, a proper duck-typed metalanguage. Duck typing does not equal "no type-safety". The problem you mention _is_ valid, but a fundamental issue in structural typing techniques. (Duck typing is a form of structural typing where the requirement-checking happens while it is being used, so to speak.) In terms of power, C++ templates _are_ comparable to Haskell typeclasses, for example - if used properly. (There are even papers comparing them.) Look up: generic programming, concepts, template metaprogramming. See the STL concept documentations for an example.
But you are right that the typing isn't enforced in the metalanguage properly. Concepts were supposed to do that, but were left out of the next revision of the language. This means that you indeed have a sort-of untyped situation, where the concept is mere documentation. You can manually replicate a concept check (which would equal the structual type checking), but this ain't trivial. However, compilation failures will happen if the concept isn't modeled properly. This is similar to the behavior in dynamic languages like Python, which use duck typing at runtime. If, say, you require something to have a foo() call, and it isn't present, the code will break when the foo() call is supposed to be made.
Also, I did not say that C# generics are template based. They aren't. They work differently, but do allow for expressions like the one I wrote, that is, without the unnecessary baggage that is an extra interface.
* first class functions, lambda, closures
First class functions are primarily the realm of functional programming languages, not procedural ones.
Lambda's, combined with ways to refer to them (C++ std::function, templates, auto) are a type of first class function.
Closures provide an interesting alternative way to code some things, but seriously who really misses them in C/C++?
Have you been living under a rock? Just about every major language out there is implementing these features. Python, C#, C++, Ruby, Javascript among others. (Java doesn't, and it is sorely missed.)
And, I do miss closures in C++. Right now I can think of several factory pattern implementations that would be greatly simplified if I could return closures instead of objects. Closures are objects are closures, sure
but they do differ in practice.
* comprehensions
Use a libary.
Good luck writing and/or finding one in C that doesn't end up requiring hundreds of lines for what can be done in at most 5 in other languages, like in Haskell.
* coroutines
Use a library.
Forget it. Coroutines work completely against the abstract machine that C models. It is a different control flow, and screws with the stack. You *may* be able to do this with Assembler code inside, but this would necessarily apply to every coroutine you write. Not good.
* painless string handling
Use a library.
No amount of C string libraries will be as convenient and easy to use as strings in other languages. C++ std::string is a good example. It is by far not the best out there, and still looks like heaven compared to the things that are usual in C. Guess why so many people use fixed char buffers for strings (and therefore cause potential buffer overflows): because proper string handling is a real PITA in C.
* module system .h/.c module definition/implementation pairs, and #ifndef/#define to allow module definitions to be blindly included.
To do what? You've listed namespaces and classes separately, so what's left that you can't do in C? Most C programmerss use paired
The .h/.c stuff is exactly what has to go. Headers are used as interfaces 99,999% of the time, and are an ugly hack. I want _proper_ modules/packages, like the ones in Python, Ruby, C#, Java, ObjC. ONE file (.cpp). Intelligent dependency tracking. The pimpl idiom, the need for include guards, and having to manually find circular #includes are some examples why this obsolete cruft has to go, and is gone in every single major programming language except for C and C++.
* reflection
C's a low level language. There is nothing to inspect. Feel free to build layers on top of it.
Oh come on. This is _exactly_ what I've said already: "Now, of course it is a valid point that these things do not necessarily belong in C. It is a system programming language, after all. But these features are very important for other domains, such as application development. Right tool for the right job, please. C is _not_ the shiny hammer, and not everything is a nail."
Of course C has evolved into C++ which has the useful items on your list, and is aquiring others (lambdas in c++0x).
I thought we were talking about K&R C....
As other posters and myself below already replied, using interfaces is just wrong. It adds unnecessary bloat, and uses the wrong type system. You want a _structured_ typing here, not a nominative one (which is what you get with interfaces). This is not about pseudo-reflection. Read below.
And guess what, in C#, C++, Python, Ruby, Javascript, Haskell, Ocaml etc. you do _not_ need an interface here. Using an interface in this case is just wrong, necessary in Java, but essentially wrong.
Generic programming requires structural, not nominative typing. The former does not care about the type's name, only about what it can do (for example, whether or not it provides a some_call member, or whether or not foo(x) would be valid if x is of that type). Nominative typing only cares about the name, it identifies the types by name. This is what you use with your interface.
In other words, the only requirement for the type should be that instance.some_call() should be a valid expression, and not that it inherits from an interface with name X.
No. K&R C lacks the following things:
* first class functions, lambda, closures
* comprehensions
* coroutines
* proper generics/templates (no, macros are _not_ a replacement)
* painless string handling
* module system
* namespaces
* reflection
* support for common oop patterns and tools, like class definitions, dynamic dispatch etc. it has to be manually constructed, which is quite time consuming
Now, of course it is a valid point that these things do not necessarily belong in C. It is a system programming language, after all. But these features are very important for other domains, such as application development. Right tool for the right job, please. C is _not_ the shiny hammer, and not everything is a nail.
Then again, Java generics are an ugly hack that applies unnecessary type erasure, because internally, generics boil down to implicit down/upcasts (either from/to Object or a specified type in case of bound generics). C# generics and C++ templates are much more powerful and do NOT apply this type erasure. For example, try to do something like template < typename T > void foo(T t) { t.some_call(); } in Java, for _any_ type that fulfills one requirement: instance.some_call() should be a valid expression.
Well, defending against such an attack would be very hard, if not impossible, since the kinetic projectiles wouldn't be easy to spot. Add their extreme speed to this, and you better have excellent equipment that can find them quickly.
On the other hand, effective counterattacks are possible. Install killer satellites in orbit, armed with high-energy lasers or kinetic weapons of their own. Or, install ground-based lasers. This kind of armament is at least a decade away, but once its there, that ship you mention would not get away unscathed.
Because now the meme has gone around to fear Jeff Goldblum's powerbook.
I like how this sounds. Imagine the announcer:
The Aliens upgraded their weapons (show new alien behemoth ship) .... but so did our heroes (show Jeff Goldblum with his iPad)
Actually, humans are way too diverse to be universally called noble or evil. Most people don't want to go out and whack some native tribes, they just want to be left alone.
Also, in Avatar, its one corporation that acts greedy and evil, not the entire human race. Plus, their actions actually are illegal in that universe..
He meant better shading capabilities. For games, it is preferable to use fewer triangles with complex shading than many triangles with simple shading.
You do *not* need the full rendering equation in most scenes. Look at what today's games are capable of achieving, and it becomes evident. Also, raytracing does not fulfill the full rendering equation, path tracing does, which is a distinctively different algorithm.
And no, primary rays are *not* handled efficiently. As said before, raytracing offers no benefits here. However, implementing caching for rasterization is pretty trivial, since its all essentially just linear interpolation, whereas caching in raytracing is hard to pull off (which means that you lose a TON of performance with raytracing here, for no visual gain). Also, again: the geometry figure is pointless, for the aforementioned reasons.
Wrong. Rasterization is good enough for around 70-80% of all scenes. This O(n) figure is completely pointless, since games prefer high-resolution textures over high-resolution geometry. Carmack said it already: we do not want more triangles, we want prettier triangles.
Also, raytracing offers absolutely no benefits for primary ray cases. Secondary, indirect rays are the ones where the actual advantages come from.
The way to go is a hybrid. Use rasterization for the primary ray cases, and actual raytracing for the secondary ones.
If you want hardware-accelerated OpenGL without lots of headache in Linux, you want Nvidia.
If you want hardware-accelerated OpenGL that supports more than OpenGL 1.4 (which is an ancient version), you want Nvidia.
ATI/AMD: driver headaches to no end. *Correct* OpenGL code causes kernel freezes, graphics glitches and so on.
Intel: the older GMAs have terrible OpenGL support and are performance-wise in the 90s. The newest GMAs are OK for low-end stuff, but only because they are actually PowerVR SGX chips, and not made by Intel.
Yeah, right. And who will decide what "obscene" means? The religious right? See the Tipper Gore comment above. .xxx, expect it to become opt-in. And then people know you watch porn. They have it in written form. This would be even worse if you had to apply for accessing specific .xxx pages.
With
This is an illusion. The inevitable consequence of a language with very little features is a considerably increase in code complexity, precisely because the language is ill-equipped to express more complex problems.
Case in point: sorting algorithms, containers, callbacks.
Please note that your comparison with C is a bad one. Do not compare Java with C. Compare Java with C++ (proper, modern C++, not "C with classes"), C#, Haskell, Ruby, Python etc.