Gee, this sounds like a familiar arguement for writing the ROM code in assembler -- of course, many vendors switched to writing their ROMs in HLL's years ago (I'm sure of C, C++, Eiffel, and Forth) because of the cost of bugs (patches are very expensive in ROMs), software development $, and time to market.
I may or may not like Java for client or server code, but Java is well designed for embedded applications. The vendor only has to write (in C or ASM most likely) the direct system routines needed to make Java able to control the system.
The exception to using Java being where the extra overhead in speed & memory (including ROM) multiplied by a large number of copies makes it worth spending more many in programming in order to reduce the cost of the product.
This does not meet Java will completely replace other HLLs in embedded code, but it does meet the goals as well as the others.
Embedded C is a perfect example of how this will work. With embedded C, unneeded parts of the standard C run-time are discarded, and the thinner remainder is a reasonable compromise for cost / performance / time to market
To a certain extent, I think the supposed Java portability is largely window dressing, and the run-time environment is often going to be trimmed (or drastically altered), but over time as CPU & memory approach $0.00, the portability will be more attractive even in the embedded market
Hardly, I immediately though of the same thing and scanned through all of the replies in flat form just to see who mentioned it first. Unfortunately, the monkey cloning is not really any such thing (only artificial twinning). I want my cloned replacement body parts, ASAP. I don't intend to live forever, but 500 years would be nice.
I went through all of the screenshots there. As expected some the same bad programming shows up over and over.
1) Many were of the variety 19100 because of the lousy years since 1900 design of unix/C/Perl, etc.
2) A number of site demonstrate the even bigger kludge of Java returning 2 digit year, unless it is 2000+, in which case it is a four digit year, thus 192000 (only some versions of java)
3) Jan 1 1900 was popular as well -- of course, this was the failure mode that was always reported by the news media. A pretty obvious programming error.
4) Dec 32 1999 was a lot more common than I would have guessed. Is there a simple algorithmic flaw that would allow this? I know that if you clock reports a julian date, and you convert this to a plaintext equivalent and you start by getting the year wrong, it would be possible to end up with December 32. But why would you have gotten the year wrong in the first place?
5) There were a couple of bizarre ones, like the year 3700. I can't image the coding errors needed to produce this.
Slashdot Mirror
Gee, this sounds like a familiar arguement for writing the ROM code in assembler -- of course, many vendors switched to writing their ROMs in HLL's years ago (I'm sure of C, C++, Eiffel, and Forth) because of the cost of bugs (patches are very expensive in ROMs), software development $, and time to market.
I may or may not like Java for client or server code, but Java is well designed for embedded applications. The vendor only has to write (in C or ASM most likely) the direct system routines needed to make Java able to control the system.
The exception to using Java being where the extra overhead in speed & memory (including ROM) multiplied by a large number of copies makes it worth spending more many in programming in order to reduce the cost of the product.
This does not meet Java will completely replace other HLLs in embedded code, but it does meet the goals as well as the others.
Embedded C is a perfect example of how this will work. With embedded C, unneeded parts of the standard C run-time are discarded, and the thinner remainder is a reasonable compromise for cost / performance / time to market
To a certain extent, I think the supposed Java portability is largely window dressing, and the run-time environment is often going to be trimmed (or drastically altered), but over time as CPU & memory approach $0.00, the portability will be more attractive even in the embedded market
I ran this query on Alta Vista and got 20 hits. I doubt any of them had anything with do with Waxman getting laid however.
I can assure you than people do buy cars using a single credit card. Expensive cars.
A friend purchased a new Jag on his American
Express one day, just because he liked it.
(Unfortunately, not a good enough friend, cause
he did not get one for me)
Hardly, I immediately though of the same thing and scanned through all of the replies in flat form just to see who mentioned it first.
Unfortunately, the monkey cloning is not really any such thing (only artificial twinning). I want my cloned replacement body parts, ASAP. I don't intend to live forever, but 500 years would be nice.
I went through all of the screenshots there. As expected some the same bad programming shows up over and over.
1) Many were of the variety 19100 because of the lousy years since 1900 design of unix/C/Perl, etc.
2) A number of site demonstrate the even bigger kludge of Java returning 2 digit year, unless it is 2000+, in which case it is a four digit year, thus 192000 (only some versions of java)
3) Jan 1 1900 was popular as well -- of course, this was the failure mode that was always reported by the news media. A pretty obvious programming error.
4) Dec 32 1999 was a lot more common than I would have guessed. Is there a simple algorithmic flaw that would allow this? I know that if you clock reports a julian date, and you convert this to a plaintext equivalent and you start by getting the year wrong, it would be possible to end up with December 32. But why would you have gotten the year wrong in the first place?
5) There were a couple of bizarre ones, like the year 3700. I can't image the coding errors needed to produce this.