No, it would be a runtime error like casting a String to Object then to Integer. Wow, you are really obtuse.
A runtime error? What's the point of java generics except to save on typing casts?
It really amazes me that Microsoft can copy something already largely done, Java, and hopelessly screw up the their own implementation so it is very difficult to make fast and at the same time screw over their customers with a very narrow, rigid, confining generics system. Come back when C# gets wildcard types for instance; the guy who got them into Java, now stolen away and working for MS, has pretty much admitted it's impossible with the CLR's messed up type system. It's sad really, it's like Microsoft has some kind of corporate policy to saddle us with 3rd-rate crap.
You have to be kidding. Java's generics implementation has limited them totally. Tell me why List{String}.class == List{Dog}.class. Do you consider that a good type system?
You do NOT want wildcards for generics because wildcards are a big ugly hack and hacking them onto the C# would be a piece of piss (there would be no need to hack the CLR cause it's just compiler magic).
Please reply with a link to the guy who said that wildcards couldn't be hacked onto C#.
You still haven't explained your paragraph where you stated that calls with CLR generics are slower because the CLR has to "check" that the type is compatible despite the fact that these checks are performed when a method is call and despite the fact that the checks are unnecessary because the CLR has NO support for covariance or contravariance.
Should have read:
You still haven't explained your paragraph where you stated that calls with CLR generics are slower because the CLR has to "check" that the type is compatible despite the fact that these checks are NOT performed when a method is called and despite the fact that the checks (if they were even required which they never are) are unnecessary because the CLR has NO support for covariance or contravariance.
So in other words C# doesn't have real generic types *and* it has broken inheritance? For instance you can't refine a method taking Map in a subclass to be one taking Map, where Integer inherits from Number? That sounds pretty broken to me, and judging by the message boards I'm not alone.
No, in other words you know nothing about generics. If that was supported, unless you had language features defining which methods are read only, you would end up adding Integers into a map of Numbers. The next version of C# will improve upon the current generics by supporting co and contravariance.
You call this generics when that holds but "List{string} instanceof List{object}" is false? C# generics are bullet points.
Well duh. Again, if List{string] was a List{object} then I could cast List{string} into List{object} and insert any object into a list of strings. Not the point of generic collections is it?
Note that I was talking about CLR not C#, so it it you who are confused. CLR supports covariant and contravariant generic types, see Eiffel CLR for instance. Are you trying to say that it uses different optimizations when the code doesn't use these? That's fair, if true. CLR must be a seriously complicated machine to be able to support all of these uses in the same program. It's no wonder then that it isn't doing the advanced optimizations (CLR often can't even inline one method let alone several deep like a JVM does... see Eric's blog posts on this subject).
You are full of it. Regardless of whether you were talking about the CLR or not, The CLR does not support covariant and constravariant generic types, the other languages perform hacks in the same way that Eiffel for.NET hacks on multiple inheritance support.
You still haven't explained your paragraph where you stated that calls with CLR generics are slower because the CLR has to "check" that the type is compatible despite the fact that these checks are performed when a method is call and despite the fact that the checks are unnecessary because the CLR has NO support for covariance or contravariance.
You seem to only have a passing understanding of generics and the CLR.
With "real" generics the system has two choices: either generate lots of bloated specific instances of the code, or add type-checking at runtime. CLR designers thought they were going to do the former and it was going to be 'uber leet' and fast, but found out it's not practical (most of the optimizations that C++ uses to limit bloat do not apply well in a dynamic language) so they got stuck with the latter, for objects.
You don't know what you're talking about. Code takes only a fraction of the memory an application uses. The CLR does NOT generate different specific instances of code for reference types. It only generates different sets of code for each specialization that is based on a valuetype (because the layout of valuetypes are different between different types as opposed to a 4 byte reference for reference types).
On top of that, the tests CLR has to do are *much* slower since they have to check many parallel type hierarchies (one per generic type references). For example, when passing a LinkedList of Integers to a parameter of type List of Numbers CLR has to in effect check both List assignable from LinkedList and Number assignable from Integer.
Admit it. You just completely made that up.
Firstly, C# currently does not support covariance. You cannot treat a LinkedList of Integers as a LinkedList of Numbers (they are two incompatable types) -- if you could, then the method could add a Number to a list of Integers which would be wrong. Java uses wildcards to let the compiler allow you to do this when you need to. Microsoft have a much more advanced mechanism planned for a future release of C#.
Secondly, the check to make sure an argument is compatible with the method call is performed statically *ONCE* when the code prepared for JIT by a code verifier. Both Java bytecode and IL are designed to be statically verified. You can't seriously think that the argument types are validated with each method call do you?
So in the vast majority of code not only do you end up with more checks but slower ones, and CLR has to maintain a complicated hierarchy of instantiated types to optimize this. All so primitives can be used faster in some cases, which is pretty ironic since in my experience these cases are usually easy to optimize by hand to use an array or patch out to inline C++ or JNI'd code.
Total hogwash. That's like saying Java's anonymous inner classes slow down java because of all the extra classes they generate. Despite what lef others to believe, The JVM is not capable of removing all the necessary cast checks and you totally ignore the issue of GC and heap overloading when needing to unecessarily box collections of primitive types.
Microsoft and Sun went totally different directions when implementing generics. Sun chose backwards compatibility (understandable considering the age and wide adoptance of the langauge at the time) whilst Microsoft had more oppurtunity make adopt a slightly better design. Both are good and have their advantages and disadvantages. I personally like Microsoft's implementation mostly because specialized generic types in C# are individual types in their on right and you can see this when you perform reflection or dynamic runtime operations upon them (typeof(List{string}) != typeof(List{object}) shows that they are seperate unique classes rather than all based on the same type/class.
I'm dismayed that you got modded to 5 considering how totally uninformed and made up your post was. None of your points are even close to the truth.
The whole frightens me. It seems absolutey crazy to encourage the use of nuclear fission in an atmosphere.
What exactly is wrong with nuclear fission for power generation? You make it sound like it's burnt in an open fire. Care to explain what you mean by "in an atmosphere"?
There are to many things that can go wrong not to mention that there is no proven safe way as of yet to deal with the waste permanently
What are these "many things" that can go wrong and why are they worse than the numerous coal mine accidents and huge amounts of uranium that is released by burning coal in the atmosphere.
Except that in this application, the user data is never going to be fixed length. Font names aren't fixed length. Sentences, paragraphs and lines aren't fixed length. Style names aren't fixed length. Even if your encapsulation uses fixed length delimiters, there's inherently going to be a lot of scanning and interpreting of variable length data.
That's true but binary formats can support file-system like clusters or simply pad small blocks with nulls that can be used to expand the block if its content size changes.
I hear this kind of speach a lot and it concerns me. It seems to me that basically all data files (or network packets, etc.) are binary formats. What's really in question is what kind of higher-level data structures are imposed on those binary formats. ODT XML files are binary files. So are old Word 2003.doc files. So are Microsoft's new XML files. So it's pointless to claim that a "binary" file format is faster than an XML file format. Perhaps that MS guy meant to say, "XML-based file formats are slower than non-XML-based file formats." At least this is a coherent claim, even if it's not necessarily correct.
Um. No. When people say "binary" they mean a format that stores data as it would be stored in memory. Endianess aside, 32bit integers are stored as 4 bytes that can be mapped to memory whereas in "text" formats like XML, 32bit integers are stored as variable length ascii characters "1024" or "16" for example.
ANY programmer without a cork up their behind understands the terminology and the distinction. No programmer would call source code "binary" and compiler produced executables "non-binary". Ultimate both are represented as binary in hardware in the form of a series of transistors but that does not undermine the accepted and standard distinction between of binary and non-binary protocols or file formats.
Your string pulling wrt to this makes you sound like a novice trying to look like an expert.
The other big mistake: file formats aren't fast or slow. The algorithms for reading and writing them are (or aren't) slow. Marino Marcich of the ODF Alliance implicitely made this point when he said that different ODF-capable applications have different performances. Perhaps you could, in a fit of brilliant computer science analysis, prove that no reader for a particular file format could parse it as fast as Word 2000 can parse a.doc file, but no one has made that claim.
Well that's also far from true. Algorithms play a big part but the design of the format is just as important (if not more). There's a big reason why SQL databases don't store data natively in a text format. It's slower. Updating parts of a file with a format like XML almost always requires rewriting the entire file because data is variable length. Additionally, parsing "1024" instead of just reading the 4 bytes into memory can be slow. Memory mapping a file is also not possible with XML. Imagine photoshop trying to load and edit a 1024MB image stored in XML. Memory mapping would not be possible so the entire file would have to be loaded into memory and converted into a binary bitmap format for processing.
VM that will check each and every access to ensure that only valid operations are allowed
Uh no. VMs have verifiers that *statically* verify that code can't do anything unsafe. Verifying dynamically whilst the code is running is not required except for some things like array accesses and even then, many of those checks can be removed.
That's a pretty inefficient way to work with a tablet pc. My tablet PC gets 99% accuracy with my handwriting. I've added all the words I use regularly that aren't already into the dictionary to the dictionary.
Let's say for a second its only a 1% hit: 1% of 200 Mhz = 2 Mhz wasted, 1% of 2.4 Ghz = 24.58 Mhz wasted.
In reality the overhead from microkernels isn't proportional like that. You may need say, 200 instructions vs 20 instructions to invoke some system call but that 200 will, for the most part remain constant. Most of the "meat" will happen strictly in user space or strictly in kernel space (the method you're calling) and as processers get faster, the overhead of microkernels becomes increasingly negligible.
Just wanted to add that the locking optimisation uses a spinlock to aquire the lock-bit(s) on an object but if that fails (another thread locked the object using the lock bit) then the thread without the lock will create a mutex and wait on that. A thread will not spin indefninitely waiting for an object's lock to be released. The mutex is only created if an object has already been locked (which, in many applications is not the common case). Most VMs that implement this also implement a mutex recycling scheme where a pool of mutexes from released objects is mainted. This speeds up cases where there is contention as a lock doesn't need to be created from scratch.
So, if you're doing multithreaded programming with Java, you're "encouraged" to have helter-skelter mutexes (i.e. a mutex on each "structure", aka whatever-you-like-to-call-it). That's dangerous and inefficient
Spoken like someone who knows nothing about Java. Firstly, just cause the language makes it easy to use any object as a point of reference for locking, it doesn't make it any worse than any other language. A programmer will generally only use an object for a lock if it is needed. No worse than C, just easier to do.
Secondly, modern JVMs don't require mutexes to be created at all. Most times, synchronization statements occur when the object isn't actually locked by another thread (no contention). Because of the high level abstractions that the JVM provides, it can replace a mutex and use a spinlock instead. One or more bits in every object's header is used as a lock marker or counter. This fast-path optimisation accounts for over 95% of lock statements and makes what would otherwise be a context-switch into the kernel, a few userland operations. All this allows programmers to make their code thread-safe (by always using locks) rather than not using locks out of fear that it will cause speed issues.
I was the developer who wrote the threading/monitor/locking code for dotgnu. Synchronization in modern VM based languages is usually much more efficient than anything almost all C users will write.
Java and C# a *more* thread oriented than languages like C/C++. Garbage collection removes almost all worries about object lifetimes and native language support for not just simple mutex-like synchronization but for monitors with wait/pulse/notify semantics are supported by default. No extra libraries or system calls are required.
The US is concerned with civilian losses (does not look good at home) but would China care about having that kind of accuracy or would carpet bombing ww2 style work well (or better) for them?
As I understand it, your draft-dodging President was allegedly trained as a pilot, but they never actually could produce sufficient documentation to prove that he was ever actually there long enough to do his training.
No one has EVER stuck it to the President and the rest of the government this seriously at this event. EVER
I thought he was a comedian. I wish he would stop with the self-righteous, smug, arrogant "comedy" that he produces both on CC and during the event.
close. Not to say no one would, but has a comedian ever had THIS much material? And considering how aggressive the material was, I doubt many would have the guts.
Then why didn't he use it rather than just talk about Iraq? The other stuff was typical of *any* administration.
Cheers to Stephen Colbert for not pulling any punches, which no one has ever done at this event.
You're congratulating him for being self-serving? He couldn't even put his politics (and it is just politics, he is not a prophet) aside for one evening and instead used it to boost his career? Oh well, I guess he did well enough to get a job hosting the Emmys next year and maybe even another 4 year contract for his show on CC.
Slashdot Mirror
No, it would be a runtime error like casting a String to Object then to Integer. Wow, you are really obtuse.
A runtime error? What's the point of java generics except to save on typing casts?
It really amazes me that Microsoft can copy something already largely done, Java, and hopelessly screw up the their own implementation so it is very difficult to make fast and at the same time screw over their customers with a very narrow, rigid, confining generics system. Come back when C# gets wildcard types for instance; the guy who got them into Java, now stolen away and working for MS, has pretty much admitted it's impossible with the CLR's messed up type system. It's sad really, it's like Microsoft has some kind of corporate policy to saddle us with 3rd-rate crap.
You have to be kidding. Java's generics implementation has limited them totally. Tell me why List{String}.class == List{Dog}.class. Do you consider that a good type system?
You do NOT want wildcards for generics because wildcards are a big ugly hack and hacking them onto the C# would be a piece of piss (there would be no need to hack the CLR cause it's just compiler magic).
Please reply with a link to the guy who said that wildcards couldn't be hacked onto C#.
For a property unhacked solution to wildcards, please read this and learn something: http://research.microsoft.com/research/pubs/view.
You still haven't explained your paragraph where you stated that calls with CLR generics are slower because the CLR has to "check" that the type is compatible despite the fact that these checks are performed when a method is call and despite the fact that the checks are unnecessary because the CLR has NO support for covariance or contravariance.
Should have read:
You still haven't explained your paragraph where you stated that calls with CLR generics are slower because the CLR has to "check" that the type is compatible despite the fact that these checks are NOT performed when a method is called and despite the fact that the checks (if they were even required which they never are) are unnecessary because the CLR has NO support for covariance or contravariance.
So in other words C# doesn't have real generic types *and* it has broken inheritance? For instance you can't refine a method taking Map in a subclass to be one taking Map, where Integer inherits from Number? That sounds pretty broken to me, and judging by the message boards I'm not alone.
No, in other words you know nothing about generics. If that was supported, unless you had language features defining which methods are read only, you would end up adding Integers into a map of Numbers. The next version of C# will improve upon the current generics by supporting co and contravariance.
You call this generics when that holds but "List{string} instanceof List{object}" is false? C# generics are bullet points.
Well duh. Again, if List{string] was a List{object} then I could cast List{string} into List{object} and insert any object into a list of strings. Not the point of generic collections is it?
Note that I was talking about CLR not C#, so it it you who are confused. CLR supports covariant and contravariant generic types, see Eiffel CLR for instance. Are you trying to say that it uses different optimizations when the code doesn't use these? That's fair, if true. CLR must be a seriously complicated machine to be able to support all of these uses in the same program. It's no wonder then that it isn't doing the advanced optimizations (CLR often can't even inline one method let alone several deep like a JVM does... see Eric's blog posts on this subject).
You are full of it. Regardless of whether you were talking about the CLR or not, The CLR does not support covariant and constravariant generic types, the other languages perform hacks in the same way that Eiffel for
You still haven't explained your paragraph where you stated that calls with CLR generics are slower because the CLR has to "check" that the type is compatible despite the fact that these checks are performed when a method is call and despite the fact that the checks are unnecessary because the CLR has NO support for covariance or contravariance.
You seem to only have a passing understanding of generics and the CLR.
With "real" generics the system has two choices: either generate lots of bloated specific instances of the code, or add type-checking at runtime. CLR designers thought they were going to do the former and it was going to be 'uber leet' and fast, but found out it's not practical (most of the optimizations that C++ uses to limit bloat do not apply well in a dynamic language) so they got stuck with the latter, for objects.
You don't know what you're talking about. Code takes only a fraction of the memory an application uses. The CLR does NOT generate different specific instances of code for reference types. It only generates different sets of code for each specialization that is based on a valuetype (because the layout of valuetypes are different between different types as opposed to a 4 byte reference for reference types).
On top of that, the tests CLR has to do are *much* slower since they have to check many parallel type hierarchies (one per generic type references). For example, when passing a LinkedList of Integers to a parameter of type List of Numbers CLR has to in effect check both List assignable from LinkedList and Number assignable from Integer.
Admit it. You just completely made that up.
Firstly, C# currently does not support covariance. You cannot treat a LinkedList of Integers as a LinkedList of Numbers (they are two incompatable types) -- if you could, then the method could add a Number to a list of Integers which would be wrong. Java uses wildcards to let the compiler allow you to do this when you need to. Microsoft have a much more advanced mechanism planned for a future release of C#.
Secondly, the check to make sure an argument is compatible with the method call is performed statically *ONCE* when the code prepared for JIT by a code verifier. Both Java bytecode and IL are designed to be statically verified. You can't seriously think that the argument types are validated with each method call do you?
So in the vast majority of code not only do you end up with more checks but slower ones, and CLR has to maintain a complicated hierarchy of instantiated types to optimize this. All so primitives can be used faster in some cases, which is pretty ironic since in my experience these cases are usually easy to optimize by hand to use an array or patch out to inline C++ or JNI'd code.
Total hogwash. That's like saying Java's anonymous inner classes slow down java because of all the extra classes they generate. Despite what lef others to believe, The JVM is not capable of removing all the necessary cast checks and you totally ignore the issue of GC and heap overloading when needing to unecessarily box collections of primitive types.
Microsoft and Sun went totally different directions when implementing generics. Sun chose backwards compatibility (understandable considering the age and wide adoptance of the langauge at the time) whilst Microsoft had more oppurtunity make adopt a slightly better design. Both are good and have their advantages and disadvantages. I personally like Microsoft's implementation mostly because specialized generic types in C# are individual types in their on right and you can see this when you perform reflection or dynamic runtime operations upon them (typeof(List{string}) != typeof(List{object}) shows that they are seperate unique classes rather than all based on the same type/class.
I'm dismayed that you got modded to 5 considering how totally uninformed and made up your post was. None of your points are even close to the truth.
because they put security above happy travellers, but the rest of the world has different priorities.
Geee, I wonder why Israel would do that?
Dear Aunt, let's set so double the killer delete select all
Oh
I assume they meant generic storage drives. Why would anyone want a rotating magnetic disk drive that small and as jewlery?
Meanwhile, drives with mere hundreds of gigabytes will be small enough to wear as jewelry.
Um, can't we already do that? I mean, Transflash drives are only 15x11x1 millimetres and can hold 2GB (to date).
The amount of and physical size of flash storage you can buy for less than $100 now is ridiculous.
The whole frightens me. It seems absolutey crazy to encourage the use of nuclear fission in an atmosphere.
What exactly is wrong with nuclear fission for power generation? You make it sound like it's burnt in an open fire. Care to explain what you mean by "in an atmosphere"?
There are to many things that can go wrong not to mention that there is no proven safe way as of yet to deal with the waste permanently
What are these "many things" that can go wrong and why are they worse than the numerous coal mine accidents and huge amounts of uranium that is released by burning coal in the atmosphere.
The problem is, clustering and padding have significant overhead. There's a reason why FAT isn't a high performance file system.
Eh? And what about every other file system and rdbms that uses clustering?
Except that in this application, the user data is never going to be fixed length. Font names aren't fixed length. Sentences, paragraphs and lines aren't fixed length. Style names aren't fixed length. Even if your encapsulation uses fixed length delimiters, there's inherently going to be a lot of scanning and interpreting of variable length data.
That's true but binary formats can support file-system like clusters or simply pad small blocks with nulls that can be used to expand the block if its content size changes.
Your mods are on crack.
.doc files. So are Microsoft's new XML files. So it's pointless to claim that a "binary" file format is faster than an XML file format. Perhaps that MS guy meant to say, "XML-based file formats are slower than non-XML-based file formats." At least this is a coherent claim, even if it's not necessarily correct.
.doc file, but no one has made that claim.
I hear this kind of speach a lot and it concerns me. It seems to me that basically all data files (or network packets, etc.) are binary formats. What's really in question is what kind of higher-level data structures are imposed on those binary formats.
ODT XML files are binary files. So are old Word 2003
Um. No. When people say "binary" they mean a format that stores data as it would be stored in memory. Endianess aside, 32bit integers are stored as 4 bytes that can be mapped to memory whereas in "text" formats like XML, 32bit integers are stored as variable length ascii characters "1024" or "16" for example.
ANY programmer without a cork up their behind understands the terminology and the distinction. No programmer would call source code "binary" and compiler produced executables "non-binary". Ultimate both are represented as binary in hardware in the form of a series of transistors but that does not undermine the accepted and standard distinction between of binary and non-binary protocols or file formats.
Your string pulling wrt to this makes you sound like a novice trying to look like an expert.
The other big mistake: file formats aren't fast or slow. The algorithms for reading and writing them are (or aren't) slow. Marino Marcich of the ODF Alliance implicitely made this point when he said that different ODF-capable applications have different performances. Perhaps you could, in a fit of brilliant computer science analysis, prove that no reader for a particular file format could parse it as fast as Word 2000 can parse a
Well that's also far from true. Algorithms play a big part but the design of the format is just as important (if not more). There's a big reason why SQL databases don't store data natively in a text format. It's slower. Updating parts of a file with a format like XML almost always requires rewriting the entire file because data is variable length. Additionally, parsing "1024" instead of just reading the 4 bytes into memory can be slow. Memory mapping a file is also not possible with XML. Imagine photoshop trying to load and edit a 1024MB image stored in XML. Memory mapping would not be possible so the entire file would have to be loaded into memory and converted into a binary bitmap format for processing.
VM that will check each and every access to ensure that only valid operations are allowed
Uh no. VMs have verifiers that *statically* verify that code can't do anything unsafe. Verifying dynamically whilst the code is running is not required except for some things like array accesses and even then, many of those checks can be removed.
That's a pretty inefficient way to work with a tablet pc. My tablet PC gets 99% accuracy with my handwriting. I've added all the words I use regularly that aren't already into the dictionary to the dictionary.
Care to back that up with some reasoning?
Let's say for a second its only a 1% hit: 1% of 200 Mhz = 2 Mhz wasted, 1% of 2.4 Ghz = 24.58 Mhz wasted.
In reality the overhead from microkernels isn't proportional like that. You may need say, 200 instructions vs 20 instructions to invoke some system call but that 200 will, for the most part remain constant. Most of the "meat" will happen strictly in user space or strictly in kernel space (the method you're calling) and as processers get faster, the overhead of microkernels becomes increasingly negligible.
Just wanted to add that the locking optimisation uses a spinlock to aquire the lock-bit(s) on an object but if that fails (another thread locked the object using the lock bit) then the thread without the lock will create a mutex and wait on that. A thread will not spin indefninitely waiting for an object's lock to be released. The mutex is only created if an object has already been locked (which, in many applications is not the common case). Most VMs that implement this also implement a mutex recycling scheme where a pool of mutexes from released objects is mainted. This speeds up cases where there is contention as a lock doesn't need to be created from scratch.
So, if you're doing multithreaded programming with Java, you're "encouraged" to have helter-skelter mutexes (i.e. a mutex on each "structure", aka whatever-you-like-to-call-it). That's dangerous and inefficient
Spoken like someone who knows nothing about Java. Firstly, just cause the language makes it easy to use any object as a point of reference for locking, it doesn't make it any worse than any other language. A programmer will generally only use an object for a lock if it is needed. No worse than C, just easier to do.
Secondly, modern JVMs don't require mutexes to be created at all. Most times, synchronization statements occur when the object isn't actually locked by another thread (no contention). Because of the high level abstractions that the JVM provides, it can replace a mutex and use a spinlock instead. One or more bits in every object's header is used as a lock marker or counter. This fast-path optimisation accounts for over 95% of lock statements and makes what would otherwise be a context-switch into the kernel, a few userland operations. All this allows programmers to make their code thread-safe (by always using locks) rather than not using locks out of fear that it will cause speed issues.
I was the developer who wrote the threading/monitor/locking code for dotgnu. Synchronization in modern VM based languages is usually much more efficient than anything almost all C users will write.
Java and C# a *more* thread oriented than languages like C/C++. Garbage collection removes almost all worries about object lifetimes and native language support for not just simple mutex-like synchronization but for monitors with wait/pulse/notify semantics are supported by default. No extra libraries or system calls are required.
The US is concerned with civilian losses (does not look good at home) but would China care about having that kind of accuracy or would carpet bombing ww2 style work well (or better) for them?
a richer cultural history ; I love the diversity
Europe diverse? Are you insane? And where do you think Australia's "cultural history" comes from?
greater diversity and numbers of job opportunities for our kids
Uh huh. That would explain the kids going round burning cars every night in Paris.
GAY HOMELAND SECURITY GUY: I'll have to use a machine-coded matrix, but I should be able to track her through the binary.
Heh, I loved that too. I also liked it how Chloe deleting files off the server made their live satellite feed go fuzzy.
As I understand it, your draft-dodging President was allegedly trained as a pilot, but they never actually could produce sufficient documentation to prove that he was ever actually there long enough to do his training.
You're talking out your ass
Uh, in its day, Microsoft' VM was the fastest. Microsoft was shipping JIT for Java whilst sun was still shipping their slow-ass interpreted runtime.
How about less heresay and more facts next time eh?
No one has EVER stuck it to the President and the rest of the government this seriously at this event. EVER
I thought he was a comedian. I wish he would stop with the self-righteous, smug, arrogant "comedy" that he produces both on CC and during the event.
close. Not to say no one would, but has a comedian ever had THIS much material? And considering how aggressive the material was, I doubt many would have the guts.
Then why didn't he use it rather than just talk about Iraq? The other stuff was typical of *any* administration.
Cheers to Stephen Colbert for not pulling any punches, which no one has ever done at this event.
You're congratulating him for being self-serving? He couldn't even put his politics (and it is just politics, he is not a prophet) aside for one evening and instead used it to boost his career? Oh well, I guess he did well enough to get a job hosting the Emmys next year and maybe even another 4 year contract for his show on CC.
Are you retarded? His side show regarding WMD just shows that he is confident that, despite there being no WMD, going into Iraq was right.