All this engineering mubmo jumbo about segemented stacks is for weenies. Languages Features are the most important part of a language, how it runs isn't important anymore.
Yeah, and all this talk about automated memory management (garbage collection) and array bounds checking is for weenies too.
Seriously, safety from stack overflow is a language feature, just like reliable tail recursion.
Java's developed at a glacial pace in comparison to C#? Um. Have you noticed that C# doesn't have generics yet ("planned for Whidbey") and yet Java has had them for about a year?
> C# is ECMA standardized. Java is wholly owned by Sun. Sun has repeatedly balked at standardizing Java due to the inherent loss of control.
I suggest you write the following lists side-by-side:
On the left, list the companies with members on the standards committe participating in defining the specification of upcoming versions of the Java language (JSRs 14, 175, 176 and 201). Count how many times each company appears on these lists, too.
On the right, list the companies with members on the standards committe participating in defining the specification of upcoming versions of the C# language.
> Also, Java generics don't support value types or > primitives, and they expand at compile time which > can cause code bloat.
No, Java generics do not expand at compile time. Each class generates a single class file. And yes, with boxing/unboxing going into 1.5 you can use primitive types with collections.
No relation at all. That is for covariant return types on methods, this is for covariant (and contravariant) generic type parameters.
Re:Interested in learning more about these generic
on
Preview of Java 1.5
·
· Score: 1
> Still, I don't remember syntax for handlign > covariance, contravariance, invariance, etc. > Was it there and I didn't see it, or are Java > 1.5's generics truly different form C++ > templates.
Java generics are fundamentally quite different from C++ templates. There is nothing like covariance etc in C++ templates.
> Despite Sun's control over the standard, they > really no longer control the direction for the > language.
Oh, really? Who, pray tell, has specified and implemented the (proposed) upcoming (Tiger, 1.5) language features for Java: JSR 14 (Generics), Foreach loops, Enums, static import, and autoboxing (JSR 201), and metadata (JSR 175). Sure, they are subject to the community process, but the core language spec JSRs are led by Sun and the only "prototype" implementations are from Sun.
The latest evidence is that gamma ray bursts are caused by supernovae of large spinning stars; the bursts are only visible when viewed from the axis of the spin. From off axis a normal supernova is seen. I quote below from this article from New Scientist which cites an article submitted to the Astrophysical Journal. Consequently, these objects are not necessarily as energetic as was previously
thought.
The link between mysterious gamma ray bursts and huge supernova explosions has finally been nailed.
Astronomers have wondered for decades what causes gamma ray bursts (GRBs). They are most violent explosions in the Universe, unleashing high-energy gamma rays and originating billions of light years from Earth. Likely culprits were thought to be supernovae, giant stars that explode after running out of fuel, and black holes.
Although astronomers have seen light characteristic of supernovae coming from the same position as GRBs in the sky, they have never been able to confirm this was not a coincidence.
Now a team lead by Kris Stanek at the Harvard-Smithsonian Center for Astrophysics in Cambridge and Peter Garnavich of the University of Notre Dame have done this by tracing the afterglow of GRB 011121 which occurred in November 2001.
In work submitted to the Astrophysical Journal, Stanek says the afterglow faded quickly over several hours, but then brightened a couple of weeks later and faded again, just as would be expected if the burst was part of a giant supernovae. "We were thrilled to be the first to catch a supernova 'in the act,'" he says.
When a giant spinning star begins to collapse, theory predicts that it shoots out bright jets, which radiate high-energy gamma rays along the axis, and cool and fade quickly. When the bulk of the star later collapses, atoms will be forced into each other and rebound outwards, causing a second brightening.
"But sometimes the jets aren't pointing towards us and so we just see a normal supernova," explains Tom Matheson of Harvard-Smithsonian.
However, unlike Java, C# compiles to machine code, not byte code. Therefore C# programs do not take the performance hit that Java programs do.
This post illustrates a common misconception. Just to set the record straight, a compiler that can take advantage of both static and dynamic program information (read: a JIT) can generally produce much better code than one that only takes advantage of static program information. There are Java static compilers out there. Their steady-state performance is about the same as the JITs.
No argument with most of that, colour of eyes and disease-proneness are identifiable. Intelligence? That's utter nonsense.
Actually, this is so self-evident that you are probably assuming something subtle is meant here.
The human genome is 99% similar to the chimpanzee. Who would doubt that the 1% differences between our genomes are responsible for the obvious differences between human and chimpanzee intelligence? I don't mean to imply that we are yet capable of identifying the specific causes of human intelligence by tracing them to specific genes and their develpmental consequences. It is not clear that differences in intelligence among individual humans are the result of genetic differences at all. But there can be no doubt that human intelligence develops in an individual as a consequence of (among other things) her genome.
Slashdot Mirror
By my calculations about 10 million kilograms. Hardly a small patch of beach.
All this engineering mubmo jumbo about segemented stacks is for weenies. Languages Features are the most important part of a language, how it runs isn't important anymore.
Yeah, and all this talk about automated memory management (garbage collection) and array bounds checking is for weenies too.
Seriously, safety from stack overflow is a language feature, just like reliable tail recursion.
Java's developed at a glacial pace in comparison to C#? Um. Have you noticed that C# doesn't have generics yet ("planned for Whidbey") and yet Java has had them for about a year?
> C# is ECMA standardized. Java is wholly owned by Sun. Sun has repeatedly balked at standardizing Java due to the inherent loss of control.
I suggest you write the following lists side-by-side:
On the left, list the companies with members on the standards committe participating in defining the specification of upcoming versions of the Java language (JSRs 14, 175, 176 and 201). Count how many times each company appears on these lists, too.
On the right, list the companies with members on the standards committe participating in defining the specification of upcoming versions of the C# language.
> Also, Java generics don't support value types or
> primitives, and they expand at compile time which
> can cause code bloat.
No, Java generics do not expand at compile time. Each class generates a single class file. And yes, with boxing/unboxing going into 1.5 you can use primitive types with collections.
No relation at all. That is for covariant
return types on methods, this is for
covariant (and contravariant) generic type
parameters.
> Still, I don't remember syntax for handlign
> covariance, contravariance, invariance, etc.
> Was it there and I didn't see it, or are Java
> 1.5's generics truly different form C++
> templates.
Java generics are fundamentally quite different
from C++ templates. There is nothing like
covariance etc in C++ templates.
who has to implement the new javac.
... wait, that would be me.
Uh,
> Despite Sun's control over the standard, they
> really no longer control the direction for the
> language.
Oh, really? Who, pray tell, has specified and implemented the (proposed) upcoming (Tiger, 1.5) language features for Java: JSR 14 (Generics), Foreach loops, Enums, static import, and autoboxing (JSR 201), and metadata (JSR 175). Sure, they are subject to the community process, but the core language spec JSRs are led by Sun and the only "prototype" implementations are from Sun.
-Neal Gafter
Sun's only Java compiler engineer
This post illustrates a common misconception. Just to set the record straight, a compiler that can take advantage of both static and dynamic program information (read: a JIT) can generally produce much better code than one that only takes advantage of static program information. There are Java static compilers out there. Their steady-state performance is about the same as the JITs.
Actually, this is so self-evident that you are probably assuming something subtle is meant here.
The human genome is 99% similar to the chimpanzee. Who would doubt that the 1% differences between our genomes are responsible for the obvious differences between human and chimpanzee intelligence? I don't mean to imply that we are yet capable of identifying the specific causes of human intelligence by tracing them to specific genes and their develpmental consequences. It is not clear that differences in intelligence among individual humans are the result of genetic differences at all. But there can be no doubt that human intelligence develops in an individual as a consequence of (among other things) her genome.