And I would suggest you get some facts - yo can't just burn waterlogged crude oil by putting a match to it, any more than you can burn a puddle of diesel fuel by throwing a lit match on it.
So forget the idea of burning it on site - even if you divert ALL the energy to heating the mat, 100 watts won't do it - that's 300 btus. Nowhere near enough to get ignition started. The heat will just be conducted away as the crude turns to semi-liquid state before re-congealing.
Of course, the whole argument is ridiculous because all a compiler does is rearrange code to a format that can be better understood
Javac never produces object code that can be run on any target cpu. Hence it is not a compiler.
A real compiler replaces source code instructions with assembly language for the host platform. The linker then takes the object files and links them together with your startup library, which is more object code, and patches the result so that the first instruction that is executed after your startup lib initialization is main().
Sure, the class files don't need a JIT, but they do need an interpreter at somepoint after they are loaded in the JVM and before they are run. And to those who try to claim that you can also make a stand-alone executable with gcj, gcj is still not feature-complete - for JDK 1.1 Not even support for the old AWT. And obviously no Swing. So unless you want to relive the glory days of pre-mouse DOS to re-implement obsolete programs, gcj is not going to cut it either.
I guess you're too uninformed to know that one of the big reasons gcj hasn't taken off, is because the HotSpot type VMs outperform it a lot of the time?
No - the reason GCJ hasn't taken off is because, to date, they're still trying to get a complete implementation of JDK 1.1.
The math doesn't work. 16'x7' is 112 square feet. 33 barrels of oil (which is how much would have to be removed each day by a fleet of 5,000 skimmers) covers that to half a meter thick, and weights 4 tons. You won't be going very fast towing that with a 1/8 hp (100 watt) motor.
So, skip the self-propelled aspect, just attach floaters to the absorbent, toss them in the sea, pick them up, pass them through a wringer to squeeze out the oil instead of heating it, rea-attach the floaters and toss them back in.
By heating up the material, the oil can be removed and burnt locally and the nanofabric can be reused.
Notice the URL - it's MIT saying this, not someone mis-quoting them.
Also, good luck with that during hurricane season.
Additionally, bad math alert. To clean up 5 million barrels in 30 days with 5,000 units, each unit would have to pick up 33 barrels a day. 16'x7'= 112 square feet. A barrel is 42 gallons, and there are 7.5 gallons in a cubic foot. So, 33 barrels is 1,385 gallons, or 184.5 cubic feet. Your skimmer will be towing a chunk of oil-soaked nanofibres half a yard thick - you're not going to be making much headway dragging that with only 100 watts (1/8 horsepower).
It might start out okay, but as you collect oil, it will get worse, so take that 1 month and make it a year.
Most php code can be translated into c, then compiled into a native loadable module, and the footprint is pretty small. If you really need to, you can also port the code into it's on server process and have it process requests at native code speeds - no php run-time library required, just a bunch of c statements. You simply can't do that with java. You'll always have more overhead, even if you make your app into a java server.
The talent only needs to do the implementation once - then it can be extended or maintained by lesser luminaries. Contrast that to the extra servers, which will only grow with time because you use bloatware, and are a continuous cost.
Also, the more bloated the code, the less likely it is to be reused, since everyone figures "I can do better than that." And the more bloated the code, the more of a maintenance nightmare it becomes. Both of these also increase your costs - and software maintenance is 90% of your software cost already - a small investment on the front end pays off bigger dividends on the back end.
Just saying - Java has introduced several false economies. A decade ago, it was much easier to find programmers who knew how to manage memory - it was something that you could assume any competent programmer could do. Today? We're back to 1980s-type BASIC skills.
This is not a good thing for the industry, long-term.
And that intermediate form still requires interpretation. The.class file is no more "compiled" for the host platform than the original.java files were.
Call it what you want, but don't call it compiled - even the JIT is a just-in-time compiler - so the source.class files obviously aren't compiled.
I'd agree with you that running a binary on a non-native platform via an emulator is the semantic equivalent of scripting - in both cases, the output has to be passed through an interpreter, and this brings along all the problems of any interpreter.
That being the case, what's your point again? Java is interpreted at runtime, the same as any scripting language, the same as a non-native binary. Neither the non-native binary nor java class files are compiled for the platform. They both are just sources of bytes for the interpreter. Neither one is "compiled" as far as the platform is concerned.
IT DOESN'T WORK! It's a joke. A toy. You really can't be serious.
No AWT, no Swing, other stuff missing, and the stuff that is there, a lot is considered untested and experimental. Their current target is JDK 1.1 - remember that? February, 1997. Some things have changed a bit since then.
2.4 What is the state of AWT support?
Work is in progress to implement AWT and Java2D.
DOS days are back!!! Get your console apps ready to change the world! Reimplement Telix, Midnight Commander, PCTools, and DosShell in Java! You too can throw your mouse away by using gcj to ship "compiled Java apps".
But wait - there's MORE!
2.5 How about support for Swing?
Once AWT support is working then Swing support can be considered. There is at least one free-software partial implementations of Swing that may be usable.
Call me back when you get it working... let's see... JDK 1.1 ( the current level *mostly* supported ) was released in 1997, so gcj is only 13 years behind... oh, how does 2023 sound? You doing anything then?
Of course, if Oracle ever updates the JDK, you may want to postpone it...
See what I mean now? It would have probably been better to extend the pascal system than to invent Java. At least with pascal, you had the choice of interpreted or binary. This way, programmers who are happy managing memory can use c, and those who aren't can use pascal. It's not like Sun didn't borrow a sh*tload of concepts from Borland Delphi design team.
Java is interpreted by the JIT, which has to first compile it. That makes Java an interpreted language. Or did you forget about the JIT? The just-in-time compiler. It compiles your script... oops "compiled" class file.
Your "class" file is not compiled code, or you wouldn't need a JIT.
It is ASSHOLES LIKE YOU that make the honest people in this world look bad. Watch out because Karma is a bitch. (Sorry, I would normally use symbols or abbreviations on my profanity due to people reading at work; but I can't hide it in this specific case.)
First, I don't do resumes. I don't believe in them.
Second, on the rare occasion when I've succumbed to a request, I've "lied" - by putting LESS, not more. For example, there's still one NDA in place, and it's easier just not to mention it. That is not dishonest, and doesn't make me an asshole. I would do the same for any subsequent employer who requested it.
I know that the JIT caches native opcodes. However, this also often prevents your code from fitting into the L1 cache, so it's going to run slower. After all, the JIT still has to do a lookup into it's own opcode cache each time. It's not magic pixie dust.
Its the same reason there's an optimum size for a disk cache, and making it too big results in slower, not faster, operation. So even long-running processes might have to dump some of the cached opcodes if they want to keep the cache size reasonable.
Throw in the garbage collector, which also isn't as free as unwinding the stack, and you're always going to have a penalty at some point.
As soon as you start writing malloc() and free() calls you are not focusing on the customer's problem but focusing on the computer. But the computer should not be important.
Is it possible that as soon as you get a language so convoluted that the vast majority of the programmers using it *need* an IDE as a crutch, you've lost the ability to focus on the problem because you're battling the underlying complexity of your design environment?
No, you have 6 small functions, and the representation of each light is only 2 bytes of light state and time for the pair of lights, and 2 function pointers - one to the current state of the lights going north-south, and one for the current state of the lights going east-west.
On a 16-bit platform, those 2 pointers take a total of 4 bytes, so (2 bytes state + 4 bytes for 2 pointers) * 10,000 = 60,000 bytes.
That leaves just over 5,000 bytes for your libs (a stripped-down c lib can be under 3k since you're not doing any printf, etc.) and code.
The code to byte-shift, as well as increment the counter, can easily fit in 2k - it's just 3 functions - redlight(), yellowlight(), greenlight(). That's why you have the function pointer table. And why the code modifies the jump table when the timer is done for each light, rather than going through a switch statement. This way, you have just one if (++v > max v=base+ptr_size), or something along those lines, to switch the pointer.
So why wouldn't it fit into 64k again?
Now an external process can modify the contents of the polled memory to signal a change to any of the timers, and you're done.
Or you could explain to your existing developers that they can sit in on the process, but you want an outsiders point of view as well, to, among other things, not make anyone feel they *have* to speak up against a candidate if they're not comfortable passing judgment on someone else, or that it was "their fault" if someone was picked who later washed out.
Compiled applications are linked with the GCJ runtime, libgcj, which provides the core class libraries, a garbage collector, and a bytecode interpreter
In other words, it's still interpreted at runtime. Your class files weren't magically compiled at "compile time" to native code. It's the same as old dBase apps that you could make into executables via a compile step - it didn't compile the.dbo file, but rather bundled a copy of the dbase runtime with your code, then set the runtime's start point to the first line of your code.
The problem is that Javanistas will point to their 2,000,000 line program and say "your 200,000 line program is a toy", not realizing that they do less in 2,000,000 lines of code.
Java - the refuge of the "cut-n-paste" BASIC programmer.
The Oxford English Dictionary (OED) defines an algorithm
as "a process or set of rules".
Dale and Lewis define an algorithm as
"unambiguous instructions for solving a problem or sub-problem in
a finite amount of time using a finite amount of data".
The OED says it was first used in 1969.
Some believe that the word is derived from the name of a Persian
mathematics teacher named Muhammad ibn-Musa al-Khowarizm, one of
the first people to develop step-by-step procedures for doing
computations.
Both of these speak of implementations.
# Correct
To be correct, an algorithm
must produce results that are appropriate and complete
given any and all sets of appropriate data.
# Well-Designed
Well-designed algorithms
are precise and simple.
Since we are talking about input and results, we are talking about specific implementations, not some higher-level generalization.
It goes on to state that you can have both higher-level and lower-level (more implementation-specific) algorithms. Stop being such a Javanista. Implementations ARE algorithms in their own right, as well as a concrete expression of a higher-level algorithm. The two terms are not mutually exclusive.
this is just so wrong I don't know where to start. I'll start with escape analysis, and end with "why does Fortran code run faster than C". You really are ignorant about compilers and programing. Your C tunnel vision has blinded you from 40 years of R&D.
... and then you do neither.
She has a better response to you "points".
Call me back when your operating system is written in Java. Oh wait, Sun tried that - another failure.
Ok, so basically your reason why C is better than Java is that if you write perfect code, you never have to worry about memory issues.
Why not just write in FORTRAN? Or Assembly, even?
Sure, I'm okay with either.
What you're saying is that Java programmers don't know how to manage memory. Kind of understandable, given the bloated memory footprint of many java applications:-)
Try again - the JIT has to interpret your class file when it runs it. Java is STILL a scripting language.
Really. Your JIT is not able to run the class file directly either, btw. Yes, after it interprets it, it saves a copy to cache, but that's it. The JIT STILL has to interpret your class file first.
1970 called, They want you to go back in time and learn how to read.
Every job I've gotten has been without a resume. When I *did* depend on resumes they didn't get me a single job. So, I've cut out what doesn't work.
I tried giving a resume to one headhunter, and it quickly reminded my of why I don't. I have linux, bsd, aix all listed. "But you don't know perl". IT'S ON THE ****ING RESUME. You know, somewhere in there in the "2 decades of experience with actionscript, assembler, c, c++, clipper, css, dbase, flash, html, javascript, PERL, php, python, sql, xhr etc etc if you don't see it, ask..."
They can't read!
I'm serious. Let me state this again. THEY CAN'T READ! "perl", not "pearl". Stupid keyword searchers who don't even know what they're looking for, or would recognize it if it walked up to them with a big sign.
And if they could, they wouldn't understand it anyway. A guy with Oracle experience was told his resume wasn't passed on because he "has no SQL experience." THEY CAN'T READ!
It's just too important and complicated and common to be left to the programmer.
That says more about the sorry state of the "common programmer" than anything else. Memory management wasn't that hard for previous generations of programmers, when did it become such a problem? Oh, right - when schools started replacing c with Java.
It's NOT that complicated, just a bit tedious, and requires a bit of forethought about who "owns" the allocated memory. This is a good thing, because it makes you plan instead of just banging out code and throwing it at the wall.
Slashdot Mirror
And I would suggest you get some facts - yo can't just burn waterlogged crude oil by putting a match to it, any more than you can burn a puddle of diesel fuel by throwing a lit match on it.
So forget the idea of burning it on site - even if you divert ALL the energy to heating the mat, 100 watts won't do it - that's 300 btus. Nowhere near enough to get ignition started. The heat will just be conducted away as the crude turns to semi-liquid state before re-congealing.
The design doesn't work.
Javac never produces object code that can be run on any target cpu. Hence it is not a compiler.
A real compiler replaces source code instructions with assembly language for the host platform. The linker then takes the object files and links them together with your startup library, which is more object code, and patches the result so that the first instruction that is executed after your startup lib initialization is main().
Sure, the class files don't need a JIT, but they do need an interpreter at somepoint after they are loaded in the JVM and before they are run. And to those who try to claim that you can also make a stand-alone executable with gcj, gcj is still not feature-complete - for JDK 1.1 Not even support for the old AWT. And obviously no Swing. So unless you want to relive the glory days of pre-mouse DOS to re-implement obsolete programs, gcj is not going to cut it either.
No - the reason GCJ hasn't taken off is because, to date, they're still trying to get a complete implementation of JDK 1.1.
And no AWT, no Swing, etc.
So let's see - liggcj was released in 1999, and here we are more than 10 years later, and they still haven't caught up to JDK 1.1 (1997).
At that rate, you might get to a half-decent release (1.5) sometime around 2150.
Did you bother looking at their FAQ? Obviously not. GCJ DOESN'T WORK.
Their "mostly-completed" target is JDK 1.1 - you know, released February 1997.
No AWT.
No Swing.
Good luck with anyone taking that seriously.
So, skip the self-propelled aspect, just attach floaters to the absorbent, toss them in the sea, pick them up, pass them through a wringer to squeeze out the oil instead of heating it, rea-attach the floaters and toss them back in.
Notice the URL - it's MIT saying this, not someone mis-quoting them.
Also, good luck with that during hurricane season.
Additionally, bad math alert. To clean up 5 million barrels in 30 days with 5,000 units, each unit would have to pick up 33 barrels a day. 16'x7'= 112 square feet. A barrel is 42 gallons, and there are 7.5 gallons in a cubic foot. So, 33 barrels is 1,385 gallons, or 184.5 cubic feet. Your skimmer will be towing a chunk of oil-soaked nanofibres half a yard thick - you're not going to be making much headway dragging that with only 100 watts (1/8 horsepower).
It might start out okay, but as you collect oil, it will get worse, so take that 1 month and make it a year.
Most php code can be translated into c, then compiled into a native loadable module, and the footprint is pretty small. If you really need to, you can also port the code into it's on server process and have it process requests at native code speeds - no php run-time library required, just a bunch of c statements. You simply can't do that with java. You'll always have more overhead, even if you make your app into a java server.
The talent only needs to do the implementation once - then it can be extended or maintained by lesser luminaries. Contrast that to the extra servers, which will only grow with time because you use bloatware, and are a continuous cost.
Also, the more bloated the code, the less likely it is to be reused, since everyone figures "I can do better than that." And the more bloated the code, the more of a maintenance nightmare it becomes. Both of these also increase your costs - and software maintenance is 90% of your software cost already - a small investment on the front end pays off bigger dividends on the back end.
Just saying - Java has introduced several false economies. A decade ago, it was much easier to find programmers who knew how to manage memory - it was something that you could assume any competent programmer could do. Today? We're back to 1980s-type BASIC skills.
This is not a good thing for the industry, long-term.
Call it what you want, but don't call it compiled - even the JIT is a just-in-time compiler - so the source .class files obviously aren't compiled.
I'd agree with you that running a binary on a non-native platform via an emulator is the semantic equivalent of scripting - in both cases, the output has to be passed through an interpreter, and this brings along all the problems of any interpreter.
That being the case, what's your point again? Java is interpreted at runtime, the same as any scripting language, the same as a non-native binary. Neither the non-native binary nor java class files are compiled for the platform. They both are just sources of bytes for the interpreter. Neither one is "compiled" as far as the platform is concerned.
No AWT, no Swing, other stuff missing, and the stuff that is there, a lot is considered untested and experimental. Their current target is JDK 1.1 - remember that? February, 1997. Some things have changed a bit since then.
DOS days are back!!! Get your console apps ready to change the world! Reimplement Telix, Midnight Commander, PCTools, and DosShell in Java! You too can throw your mouse away by using gcj to ship "compiled Java apps".
But wait - there's MORE!
Call me back when you get it working ... let's see ... JDK 1.1 ( the current level *mostly* supported ) was released in 1997, so gcj is only 13 years behind ... oh, how does 2023 sound? You doing anything then?
Of course, if Oracle ever updates the JDK, you may want to postpone it ...
See what I mean now? It would have probably been better to extend the pascal system than to invent Java. At least with pascal, you had the choice of interpreted or binary. This way, programmers who are happy managing memory can use c, and those who aren't can use pascal. It's not like Sun didn't borrow a sh*tload of concepts from Borland Delphi design team.
Java is interpreted by the JIT, which has to first compile it. That makes Java an interpreted language. Or did you forget about the JIT? The just-in-time compiler. It compiles your script ... oops "compiled" class file.
Your "class" file is not compiled code, or you wouldn't need a JIT.
First, I don't do resumes. I don't believe in them.
Second, on the rare occasion when I've succumbed to a request, I've "lied" - by putting LESS, not more. For example, there's still one NDA in place, and it's easier just not to mention it. That is not dishonest, and doesn't make me an asshole. I would do the same for any subsequent employer who requested it.
I know that the JIT caches native opcodes. However, this also often prevents your code from fitting into the L1 cache, so it's going to run slower. After all, the JIT still has to do a lookup into it's own opcode cache each time. It's not magic pixie dust.
Its the same reason there's an optimum size for a disk cache, and making it too big results in slower, not faster, operation. So even long-running processes might have to dump some of the cached opcodes if they want to keep the cache size reasonable.
Throw in the garbage collector, which also isn't as free as unwinding the stack, and you're always going to have a penalty at some point.
Is it possible that as soon as you get a language so convoluted that the vast majority of the programmers using it *need* an IDE as a crutch, you've lost the ability to focus on the problem because you're battling the underlying complexity of your design environment?
On a 16-bit platform, those 2 pointers take a total of 4 bytes, so (2 bytes state + 4 bytes for 2 pointers) * 10,000 = 60,000 bytes.
That leaves just over 5,000 bytes for your libs (a stripped-down c lib can be under 3k since you're not doing any printf, etc.) and code.
The code to byte-shift, as well as increment the counter, can easily fit in 2k - it's just 3 functions - redlight(), yellowlight(), greenlight(). That's why you have the function pointer table. And why the code modifies the jump table when the timer is done for each light, rather than going through a switch statement. This way, you have just one if (++v > max v=base+ptr_size), or something along those lines, to switch the pointer.
So why wouldn't it fit into 64k again?
Now an external process can modify the contents of the polled memory to signal a change to any of the timers, and you're done.
Or you could explain to your existing developers that they can sit in on the process, but you want an outsiders point of view as well, to, among other things, not make anyone feel they *have* to speak up against a candidate if they're not comfortable passing judgment on someone else, or that it was "their fault" if someone was picked who later washed out.
Not quite ... from the description>:
In other words, it's still interpreted at runtime. Your class files weren't magically compiled at "compile time" to native code. It's the same as old dBase apps that you could make into executables via a compile step - it didn't compile the .dbo file, but rather bundled a copy of the dbase runtime with your code, then set the runtime's start point to the first line of your code.
The problem is that Javanistas will point to their 2,000,000 line program and say "your 200,000 line program is a toy", not realizing that they do less in 2,000,000 lines of code.
Java - the refuge of the "cut-n-paste" BASIC programmer.
https://users.cs.jmu.edu/bernstdh/web/common/lectures/slides_algorithms.php
Both of these speak of implementations.
Since we are talking about input and results, we are talking about specific implementations, not some higher-level generalization.
It goes on to state that you can have both higher-level and lower-level (more implementation-specific) algorithms. Stop being such a Javanista. Implementations ARE algorithms in their own right, as well as a concrete expression of a higher-level algorithm. The two terms are not mutually exclusive.
She has a better response to you "points".
Call me back when your operating system is written in Java. Oh wait, Sun tried that - another failure.
Sure, I'm okay with either.
What you're saying is that Java programmers don't know how to manage memory. Kind of understandable, given the bloated memory footprint of many java applications :-)
Try again - the JIT has to interpret your class file when it runs it. Java is STILL a scripting language.
Really. Your JIT is not able to run the class file directly either, btw. Yes, after it interprets it, it saves a copy to cache, but that's it. The JIT STILL has to interpret your class file first.
1970 called, They want you to go back in time and learn how to read.
Every job I've gotten has been without a resume. When I *did* depend on resumes they didn't get me a single job. So, I've cut out what doesn't work.
I tried giving a resume to one headhunter, and it quickly reminded my of why I don't. I have linux, bsd, aix all listed. "But you don't know perl". IT'S ON THE ****ING RESUME. You know, somewhere in there in the "2 decades of experience with actionscript, assembler, c, c++, clipper, css, dbase, flash, html, javascript, PERL, php, python, sql, xhr etc etc if you don't see it, ask ..."
They can't read!
I'm serious. Let me state this again. THEY CAN'T READ! "perl", not "pearl". Stupid keyword searchers who don't even know what they're looking for, or would recognize it if it walked up to them with a big sign.
And if they could, they wouldn't understand it anyway. A guy with Oracle experience was told his resume wasn't passed on because he "has no SQL experience." THEY CAN'T READ!
That says more about the sorry state of the "common programmer" than anything else. Memory management wasn't that hard for previous generations of programmers, when did it become such a problem? Oh, right - when schools started replacing c with Java.
It's NOT that complicated, just a bit tedious, and requires a bit of forethought about who "owns" the allocated memory. This is a good thing, because it makes you plan instead of just banging out code and throwing it at the wall.