Actually I think Web 1.0 was reminiscent of the mainframe terminal environment. Struts immediately jumps to mind. Web 2.0 reminds me more of client / server applications although its not a perfect analogy.
It should not be surprising that architectures keep shifting back and forth over the years. Each is in some sense solving certain problems of the former. But it does lead to a certain amount of "rediscovering" something that used to be well understood. I suspect that many of the younger folks would be surprised to know that the virtualization driving the cloud dates back to 1972 and the IBM System/370 range of mainframes.
I like unit testing as a tool but I get turned off by a lot of pro-unit testing comments because people tend to describe in terms of something that must always be done or the code is of questionable quality. There are many situations where unit tests can't be made in a meaningful way.
The system I work on depends on real-time data streams to provide the context that defines how something is processed. Yes I could make unit tests for each of the simple operations, but what is complicated is the way the real-time data can trigger those simple operations in so many combinations and permutations. It is not practical to write a set of unit tests where each has a precondition of setting the full system state. The typical response I get is 'Well at least write unit tests for the part that is unit testable.' My response is that the part that isn't unit testable is the interesting part. Any technique is a trade off between the effort to use it and value it returns. Writing unit tests for simple code that can be verified through visual inspection is unlikely to return the value that justifies the effort.
Unit tests are great where they can be applied effectively but like any technique should not be applied slavishly to every situation.
I've seen some damn fine images from 6 or 8 MP cameras that were far above the quality produced by some higher MP count cameras
That's because megapixel counts are misleading. You need to square the number of pixels to double the quality of the image. Jumps from 6 to 8 to 10 sound big but are negligible. I'll think about upgrading when the 36-64 megapixel cameras are out.
This was a command in Commodore 64 BASIC that would start executing machine code at the specified address. A 4k block of free memory started at address 49152 (C000) and so this was a common jump point for games and other programs. Commodore 64 fans will also remember SYS 64738.
No wait, I can't do that. The compiler threw away that information after compile.
Don't look into reflection and Generics then, it will upset your world view.
The main problem with Java over-hype is that every distinctive feature of the Java was done better in other previous languages. I think you can make a valid argument that Java brought together a lot of these features into one system, but that also feeds into bloat which is the dark side of Java.
I think the test is rather simple. When your "AI" that you bought to be the controller for an industrial robot gets bored and decides to become a poet. Well I think you have a winner on your hands.
Buckner & Garcia have an official site for the Pac Man Fever album. They sell a CD that is a newer recording of the original material. I bought it for nostalgia value. I have the original LP also but I no longer have a way to play it.
I say this because anyone who spends three seconds on it can see how someone can be anti abortion and pro capital punishment.
I think you have answered your own implied question. If you talk to a pro-choice person they would point to this contradiction (inconsistency) as an argument against pro-life. If you talk to a pro-life person they would most likely give a rationale like yours above that says there is no contradiction (inconsistency). (i.e., innocent death != criminal death)
Point of view matters greatly for whether a party even accepts that the contradiction exists. I disagree somewhat with the Eliot quote; a true contradiction is going to bother a rational person.
Traditional languages that have had threads bolted on like C/C++ make threading more challenging than it needs to be. Java, as long as you understand the principles of concurrency, makes it a breeze.
This is simply not true. The simplified constructs in Java lead to very poor locking patterns in non-trivial code. Complex Java uses the very same advanced algorithms calling the low level primitives that C/C++ would use.
Java is more dangerous in one important way. C++ contains destructors and a common locking pattern is to lock in the constructor and unlock in the destructor. This makes it very hard to have a missing unlock making the code easier to maintain.
In Java you are left with obsessive use of catch/finally to handle all possible cases manually. The syntactic sugar in Java gives the illusion that the code is easier but it is in fact no easier than any other language.
I had a professor that once said something to the effect that low level, high performance languages like C/C++ may not be the best choice in language for all projects but they are the best choice for the really interesting ones like OSes.
The Java Advanced Imaging API in the JDK offers a C-based library called mediaLib that accelerates the imaging functions because the pure Java versions can't achieve good performance.
Sun would never say this publicly but internally they recognize that Java can't achieve the performance of good optimized C code.
How dare Apple use a rechargable battery that doesn't last a life time, that is not user replaceable. The implication is that Apple specifically designed the battery not to be replaceable so that people were forced to buy new iPods, which increases Apple revenue.
Outcry from that forced Apple to offer the $90 replacement battery. However this price is still excessive which leads one to wonder if they are still ultimately hoping that customers will buy a new iPod to get the neat new features versus plunking down $90 more for an old iPod that isn't even covered under warranty any more.
.NET is more or less equivalent to the Java environment in that you have languages that compile to byte code (CLR or JVM). This is popular for writing applications but is a horrible idea for an OS kernel.
Kernels need to be small and efficient. Could you imagine someone criticizing the Linux kernel for not being written in Java?
The parent poster is confusing two completely different stories. The author who is not using his real name is Paul Murphy who wrote the story about how SCO has IBM on the ropes.
Slashdot Mirror
Actually I think Web 1.0 was reminiscent of the mainframe terminal environment. Struts immediately jumps to mind. Web 2.0 reminds me more of client / server applications although its not a perfect analogy.
It should not be surprising that architectures keep shifting back and forth over the years. Each is in some sense solving certain problems of the former. But it does lead to a certain amount of "rediscovering" something that used to be well understood. I suspect that many of the younger folks would be surprised to know that the virtualization driving the cloud dates back to 1972 and the IBM System/370 range of mainframes.
I like unit testing as a tool but I get turned off by a lot of pro-unit testing comments because people tend to describe in terms of something that must always be done or the code is of questionable quality. There are many situations where unit tests can't be made in a meaningful way.
The system I work on depends on real-time data streams to provide the context that defines how something is processed. Yes I could make unit tests for each of the simple operations, but what is complicated is the way the real-time data can trigger those simple operations in so many combinations and permutations. It is not practical to write a set of unit tests where each has a precondition of setting the full system state. The typical response I get is 'Well at least write unit tests for the part that is unit testable.' My response is that the part that isn't unit testable is the interesting part. Any technique is a trade off between the effort to use it and value it returns. Writing unit tests for simple code that can be verified through visual inspection is unlikely to return the value that justifies the effort.
Unit tests are great where they can be applied effectively but like any technique should not be applied slavishly to every situation.
Yeah you are right. Thanks for correcting my mistake. Serves me right for trying to make a post before first coffee.
I've seen some damn fine images from 6 or 8 MP cameras that were far above the quality produced by some higher MP count cameras
That's because megapixel counts are misleading. You need to square the number of pixels to double the quality of the image. Jumps from 6 to 8 to 10 sound big but are negligible. I'll think about upgrading when the 36-64 megapixel cameras are out.
I would try setting java.library.path to qtjabmi-linux-preview/lib using the -D command line argument when you run your test program.
This was a command in Commodore 64 BASIC that would start executing machine code at the specified address. A 4k block of free memory started at address 49152 (C000) and so this was a common jump point for games and other programs. Commodore 64 fans will also remember SYS 64738.
No wait, I can't do that. The compiler threw away that information after compile.
Don't look into reflection and Generics then, it will upset your world view.
The main problem with Java over-hype is that every distinctive feature of the Java was done better in other previous languages. I think you can make a valid argument that Java brought together a lot of these features into one system, but that also feeds into bloat which is the dark side of Java.
I think the test is rather simple. When your "AI" that you bought to be the controller for an industrial robot gets bored and decides to become a poet. Well I think you have a winner on your hands.
The Japanese word that means foreigner is gaijin not geijin.
An apt choice, since the band, Spock's Beard, has an album called The Beware of Darkness.
I enjoy obscure code examples as an antidote to drinking the Java is perfect Koolaid. Examples like:
private int foo()
{
try
{
return 0;
}
finally
{
return 1;
}
}
Buckner & Garcia have an official site for the Pac Man Fever album. They sell a CD that is a newer recording of the original material. I bought it for nostalgia value. I have the original LP also but I no longer have a way to play it.
I think you have answered your own implied question. If you talk to a pro-choice person they would point to this contradiction (inconsistency) as an argument against pro-life. If you talk to a pro-life person they would most likely give a rationale like yours above that says there is no contradiction (inconsistency). (i.e., innocent death != criminal death)
Point of view matters greatly for whether a party even accepts that the contradiction exists. I disagree somewhat with the Eliot quote; a true contradiction is going to bother a rational person.
This is simply not true. The simplified constructs in Java lead to very poor locking patterns in non-trivial code. Complex Java uses the very same advanced algorithms calling the low level primitives that C/C++ would use. Java is more dangerous in one important way. C++ contains destructors and a common locking pattern is to lock in the constructor and unlock in the destructor. This makes it very hard to have a missing unlock making the code easier to maintain.
In Java you are left with obsessive use of catch/finally to handle all possible cases manually. The syntactic sugar in Java gives the illusion that the code is easier but it is in fact no easier than any other language.
Hopefully it will actually spit out x^4/4 + C or there needs to be another recall. =P
I had a professor that once said something to the effect that low level, high performance languages like C/C++ may not be the best choice in language for all projects but they are the best choice for the really interesting ones like OSes.
Actually, Java is the new legacy code. :)
The Java Advanced Imaging API in the JDK offers a C-based library called mediaLib that accelerates the imaging functions because the pure Java versions can't achieve good performance.
Sun would never say this publicly but internally they recognize that Java can't achieve the performance of good optimized C code.
How dare Apple use a rechargable battery that doesn't last a life time, that is not user replaceable. The implication is that Apple specifically designed the battery not to be replaceable so that people were forced to buy new iPods, which increases Apple revenue.
Outcry from that forced Apple to offer the $90 replacement battery. However this price is still excessive which leads one to wonder if they are still ultimately hoping that customers will buy a new iPod to get the neat new features versus plunking down $90 more for an old iPod that isn't even covered under warranty any more.
.NET is more or less equivalent to the Java environment in that you have languages that compile to byte code (CLR or JVM). This is popular for writing applications but is a horrible idea for an OS kernel.
Kernels need to be small and efficient. Could you imagine someone criticizing the Linux kernel for not being written in Java?
I don't understand.
Irony is a dish best served cald...
I also enjoyed reading his theory that the GPL is destroying the free market.
The parent poster is confusing two completely different stories. The author who is not using his real name is Paul Murphy who wrote the story about how SCO has IBM on the ropes.
In this IE6 world a webdesigner cannot use transparent pngs.
This is not completely true. PNGs with 8-bit alpha channels render correctly. Google maps uses this trick to create the push pin drop shadow.
Swing lost the SWT war years ago.