It's a racket. Longevity gets you on influential committees. Influential committees mean that you get better chances of shipping pork home to the voters. And that's just the official clubs that you can get on when you've been around a while.
This is the dirty reason why the Pelosis and McConnells, the McCains and Rubios, Conyers, Grahams, Kennedys, DeLays and so forth keep their jobs forever. Because of that sweet, sweet bacon.
Maybe that's why the Muslims extremists hate us so much!
The word 'afternoon' does not exist in Spanish nor does the concept exist in Spanish minds. They eat between 3-5 p.m.
Which planet is your Spain in? On this one, "tarde" means afternoon and evening - and in tropical and sub-tropical realms, the day fades slowly compared to an English December.
Hispanic countries often don't have actual dinner until about 10:00pm.
Mad dogs and Englishmen go out in the Mid-day sun.
In the warmer latitudes, especially before air-conditioning, the post-noon hours are the hottest, most uncomfortable time of day. Between post-prandial torpor and natural biorhythm, it's only natural to want to sleep until the heat has weakend. And then there's the UV exposure factor for outdoor workers. Despite the opinions of people from chillier climates, however, this doesn't have to mean working less - more evening time is employed (also note that winter days don't get as short nearer the Equator).
Unfortunately, while a siesta is no real problem for most agricultural work or small businesses, it's harder to do when you're commuting half an hour or more to work every day and work has no napping place. And factory owners don't like it, because machines don't need to hide from the heat, and their ideal is that the worker should adapt to the machine and not vice versa.
It's "Inventory Shrinkage", technically, I think. But I wanted to make the point that there are many reasons why the numbers often don't match and even then they aren't complete. For example, when the foreman says "We've a spill in Aisle 5, grab a roll of paper towels from 7 and clean it up", that, too is part of shrinkage.
There are very compelling reasons to completely inventory a shelf periodically. Virtually everything has some sort of "sell-by" date. You want to pull the old stock to the front as part of rotation and you want to pull expired stuff entirely to avoid lawsuits of the variety you get when someone dies of botulism from an out-of-code can of green beans.
Sure, a casual scan is sufficient for daily operations, but considering how automated equipment generally works, it's entirely likely that a full scan might be just as efficient as a human's casual inventory. If all you want to do is fill holes, that is also something that can be easily automated. Tack it on to the algorithm that spots the misplaced package of bacon.
But the grocery business is very low margin to begin with. And this is after all, the Age of the Bean Counter where nothing less than 110% efficiency will do, so anything that keeps reality and the database aligned is going to be popular.
Of course, all I've mentioned so far is based on automating how existing things are done. An automated store might have palletized shelves that are rotated in and out as a unit. Kind of like the Wal-Mart of the future where self-driving trucks back up to the store, automated tow-motors pull display pallets off and place/unwrap them, and the only remaining human employees are the file of security guards that check your bags and receipt every 3 feet from the self-service register to the door.
Items on shelves =/= items stocked - items sold. There's breakage, pilferage, accidental checkout of 2 items stuck together and other things beside. Only an actual physical reconciliation can ensure that reality matches what the computers "know".
In my local store, people periodically run the aisles looking for misplaced items. When they find one, they toss it in a cart and go on until they've run the aisles. Then they sort the cart, reshelve the non-perishables, and dump the hamburger that was found next to the soft drink aisle after sitting for who knows how long.
The hardest part of this is the recognition, and machine vision is more than adequate for most of this these days even on a Raspberry Pi, I think. You would have to be a bit creative to do the sorting, especially if the picker has scooped up a few toddlers, but likely a single machine would be able to handle a whole store's worth of items.
Because the items in question are presumably not Open Source, they're
closely guarded product security secrets
Meaning that the open-source support community hasn't had a chance to vet these resources for either accidental security holes, deliberate back doors, or weak spots that this quarter's budget didn't allow fixing.
So an unfriendly power can see things that the American public cannot see, giving them an advantage in terms of exploits and exploit counter-measures.
Facts are deadly to any form of ideological purity. The world is a complex place and no one-size-fits-all solution exists.
The stock answer to why we have to keep feeding tax cuts to the 1% is "temporarily embarrassed millionaires", despite the obvious fact that very few people even ever become millionaires - much less billionaires. Or the stats that say that your best chances of being rich are by having rich parents.
But I suspect a lot of it has to do with a steady propaganda campaign that it's the Eevil Libruls who raise taxes and all they want to do is steal your hard-earned money and give it to illegal immigrants and lazy undeserving poor people. We all know, after all, that you're only poor if you're lazy and waste your money on drugs and avocado toast.. And besides, Libruls hate Freedom and would give our proud country to the Russians in a heartbeat if they weren't kept in check.
I used to be in the 30% tax bracket and lived in financial security. Nowadays I pay 8% and almost every dime goes into savings for the next time I and my co-workers get laid off. That particular lifestyle gets old. Not to mention interferes with my ability to overcome my millionaire embarrassment.
Discovery of the infection came on Sunday, more than five weeks after the onset of the NSA-derived ransomware worm
Seriously, WTF were they playing at not applying the security fixes that were released within days of WannaCry. OK, so with MS's history it pays to be careful and test each fix before widely deploying it, but 5 fucking weeks ??
"Lost" computers that don't get maintenance, misplaced priorities, lots of reasons.
That's why to this day I still register several of the original SQL server attacks on my domain, even though I don't run SQL server. Someone out there is hoping to get lucky. Sometimes they do.
By then, the rest of the world will have converted to green technology. Locally, having exhausted all our coal and with no technology to speak of thanks to decades of anti-science, limited education, and dirty energy, we'll have plenty of job opportunities - for charcoal burners. Assuming we haven't also clear-cut all the forests by then.
...and so were cellular telephones when they first came to market. All that you needed was a scanner.
In fact, it was perfectly legal under the Communications Act of 1934 to listen to - but not repeat - communications received in any mode on any frequency.
Then Reagan Got The Government Off The Backs Of The People and signed a law that made it not merely illegal to receive cellular communications, but to sell radios capable of receiving cellular communications. Land of the Free.
Not that it did much good. Cellphones of the day tended to leak over onto my police-band radio anyway. And technically whoever blew up Newt Gringrich's reign by publishing a cell call intercepted in Gainesville, Florida should have been prosecuted, but no one was.
These days, however, more communications than not are both digitized and encrypted. That includes the public-service stuff like fire departments, public transportation, routine police work and a lot more. You can no longer hear what you're paying for or how your local/state government does its day-to-day work.
It's always best to do one's own research, as it helps to avoid being fed cherry-picked reality. But, if you insist, here's some stuff I cherry-picked from Google.
The first one is very interesting because it dates all the way back to 1998, when JIT Java was fairly new, but the relative timings are quite comparable, given similar constraints:
Your Mileage can Definitely Vary, however. I found benchmarks indicating that the "Java" (Don't call it Java or Oracle's lawyers will swarm you - it's Dalvik) on Android is significantly slower.
Some of my own impressions of relative performance are dated, I think. The Gnu compilers have added some very aggressive optimizations in recent years.
The Debian benchmark seems to indicate that raw C (gcc) is on average about twice as fast as either Java or C++. My suspicion is that a lot of modern C++ coding is not only using virtual methods, but taking advantage of string and dynamic memory managers that were not part of the original C++. There is a cost for using pre-packaged solutions, but in an era where machine time is cheap but programmers still cost $10K a year even in India, shops generally favor "Git 'R Dun" over hyper-optimal performance.
I've always been partial to the definition (I think by Alan Kay) that Java is "C++ without the mace and knives". I find Java to be less stressful because I don't obsess about what raw machine code will be produced, and the rigorous compile-time checking means that I can devote more time to worrying about the high-level design. However, a JVM is a greedy thing, so there are still times when I prefer C or C++. Then again, there are times when I prefer Python, Perl, or PHP.
In the end, it's less about language and more about intelligent design. I once encounted a perfectly horrible C++ program that used a very sparse array with a widely-distributed working set. Virtually every computation triggered a page fault; I've seen cases where "efficient" sorts and searches were totally unsuitable because the data was in worst-case form. For performance, the choice of language is less important than how it's used. And above all, measure instead of simply "knowing".
The reason why I take such umbrage against the "common knowledge" that Java is slow is because that knowledge is largely based on old-time interpreter implementations, where on average, an interpreted instruction would take about 10 times longer than its native-code equivalent because a lot of the code being executed wasn't the app, it was the interpreter. JIT-compiled code has no interpreter overhead, so it's primarily limited by the optimization capabilities of the JIT compiler and the tuning settings (small code, slow code vs. fat code, fast code, for example). For lightweight apps, the overhead of launching a JVM, to say nothing of the overhead of doing the JIT compiling is obviously not worth it. For something that launches, runs 24x7 and doesn't restart for weeks at a time, those considerations are fairly trivial - assuming there's enough RAM. If you have dynamic load-balanced re-compiling, then the overall performance is likely to be better than for a static-compiled app.
But juggling instructions tends to only give you about an extra 10% boost, and on the whole, I prefer enough headroom for that not to matter. What makes or breaks most systems is the app itself. I knew of one where a single switch setting could single-handedly bring an IBM mainframe to its knees if set improperly. No compiler in the world could have helped that.
You have the right intuition, but intuition is dangerous. It's true. For really, really short one-shot code segments, the overhead of launching a Java VM is ferociously expensive, much less running monitor functions. Might as well crack walnuts with a hydraulic press.
However, as you scale up, the overhead remains more or less fixed and becomes less and less of a percentage of the overall workload. If your optimization mechanisms are any good, you eventually reach a tipover point where the overhead more than pays for itself. The benefits mostly show up in long-running and frequently-executed processes which are usually what you find in servers and the bulk of the JVM optimization functions are geared towards that environment.
I'm not in the gaming industry, but I would be cautious about a flat assertion that all games are written in C++. At least at one time, I think that there were some gaming-specific programming languages and some development environments that were designed specifically for game functions and have had years to get tuned even without machine assistance. Moreover, I think it unlikely that games are going to see a lot of shifting workloads - although that's more of a "know" thing than a measured fact - and repeated dynamic recompilation isn't necessary or useful in such cases.
I do know of one game that definitely is written in Java: Minecraft for the Raspberry Pi. The Pi is not a powerful computer by modern standards, so running Java, much less a computer game in Java on it is no small accomplishment. I've worked with mainframes that couldn't host a JVM. OK, they were really old mainframes, but still....
The conceit from the knee-biter crowd that Java is slow needs to die. I've worked with video editors, complex GUI design apps and IDEs (both Eclipse and the Arduino IDEs are Java apps) and never felt the difference between Java-based products and products written in other languages. I'm not saying that Java is the solution for all problems.
I'm not into one-size-fits-all. Leave that to the religious and political crazies. I use Java, Python, assembly language, even Fortran and COBOL, LISP, Perl and more, depending on what works best for the problem at hand. I'll happily defend any of them, and I hope I'd be just as happy to admit their respective flaws. Because if you cannot admit flaws as well as strengths, you're an ideologue and an ideologue is just an idiot with an agenda.
thus, like Java, can potentially run faster than static-compiled programs.
And yet, it never actually does.
Because you "know" it can't.
Some of us have seen actual numbers and benchmark code.
I optimize for a living and one of the first things you learn when you go to boost performance is to get hard measurements and to never, ever optimize prematurely.
Because the bottleneck is almost never where you "know" it's supposed to be.
You could start a major flame war on the subject of C++ templating. It's a powerful tool, but it's very easy to cut yourself.
Actually, if you want really strong compile (and run) time checking, the winner is Ada. It not only rigorously enforces type conformance, it also asserts domain and range validation on everything. If I define a type in ADA named POSITIVE_INTEGER and give it a domain of 1..INFINITY, assigning a negative number or zero stops the whole game on the spot.
Please don't ascribe the virtues of an IDE to a language. There is a Python plugin for the Eclipse IDE (actually more than one, I think), though offhand, I cannot recall what, if any popup help you get.
Java does have the advantage that the language is designed to be auto-documented, and that information is easy to feed to an IDE. Python tends that way, but since it doesn't keep as tight a rein on things, I don't know how much IDE support is presently available.
JIT-compiling these days [...] potentially run faster than static-compiled programs
Argh, not this phrase again... potentially but never really.
Existing Benchmarks beg to differ. There are hard numbers if you care to look them up.
YMMV, of course. A one-shot run of code may or may not run faster. One of the advantages of dynamic systems, however, is that for large-scale computations, it becomes economical to statistically analyse the code and alter it based on workload. Even in ancient times you could often gain a significant speed boost by flipping a test so that the most common instruction path did not branch or switching what working data was kept in registers. On modern processors, you can play all sorts of games by reducing bubbles in the instruction pipeline, optimizing register and cache usage, and so forth.
Using a dynamic recompilation process you can optimize on the fly to a degree that would be cost-prohibitive, if not impossible to achieve via hand optimization, and unlike static compiler systems, you can do it without stopping the process and restarting it. It's the real-world equivalent of being able to change tires on a Formula 1 race car without it ever having to slow down for a pit stop.
All true, but the question was written in a future tense: "Will Python...???". What holds true today need not hold true tomorrow. It didn't for Java, after all.
So was Java, once. Python has JIT-compiling these days, and thus, like Java, can potentially run faster than static-compiled programs.
What Python doesn't have is strong type enforcement. Unless you pre-compile the whole app, entire source files could be filled with monkey-typed gibberish and until the fateful day came that the defective modules were referenced (say, once a Leap Year), they'd be serpents in the grass.
Even pre-compiling won't help if there are insufficient cues to ensure that you won't be passing a dingus to a module that expects to use a wackdoodle.
One printout is just as unconvincing as another. The thing that brought down Dan Rather was that in his case the computer printout in question used anachronistic fonts. But an email dump with full headers can be cross-referenced back to its sources, even if you have it replicated by monks on an illuminated manuscript.
The important thing here is that the original printer isn't going to be made accessible to people trying to confirm the truth of the leaks - only to people trying to trace them.
Long before laser printers, investigators were tying people to typewriters based on unique per-unit imperfections and wear patterns. You can do something similar based on drum and toner distribution variances even on a monochrome non-watermarked printer.
Granted, the judas dots also report the date and time, which helps nail a culprit on a shared resource, but the safest thing to do would be to OCR the printed documents rather than photocopy them.
Slashdot Mirror
It's a racket. Longevity gets you on influential committees. Influential committees mean that you get better chances of shipping pork home to the voters. And that's just the official clubs that you can get on when you've been around a while.
This is the dirty reason why the Pelosis and McConnells, the McCains and Rubios, Conyers, Grahams, Kennedys, DeLays and so forth keep their jobs forever. Because of that sweet, sweet bacon.
Maybe that's why the Muslims extremists hate us so much!
The word 'afternoon' does not exist in Spanish nor does the concept exist in Spanish minds. They eat between 3-5 p.m.
Which planet is your Spain in? On this one, "tarde" means afternoon and evening - and in tropical and sub-tropical realms, the day fades slowly compared to an English December.
Hispanic countries often don't have actual dinner until about 10:00pm.
Mad dogs and Englishmen go out in the Mid-day sun.
In the warmer latitudes, especially before air-conditioning, the post-noon hours are the hottest, most uncomfortable time of day. Between post-prandial torpor and natural biorhythm, it's only natural to want to sleep until the heat has weakend. And then there's the UV exposure factor for outdoor workers. Despite the opinions of people from chillier climates, however, this doesn't have to mean working less - more evening time is employed (also note that winter days don't get as short nearer the Equator).
Unfortunately, while a siesta is no real problem for most agricultural work or small businesses, it's harder to do when you're commuting half an hour or more to work every day and work has no napping place. And factory owners don't like it, because machines don't need to hide from the heat, and their ideal is that the worker should adapt to the machine and not vice versa.
It's "Inventory Shrinkage", technically, I think. But I wanted to make the point that there are many reasons why the numbers often don't match and even then they aren't complete. For example, when the foreman says "We've a spill in Aisle 5, grab a roll of paper towels from 7 and clean it up", that, too is part of shrinkage.
There are very compelling reasons to completely inventory a shelf periodically. Virtually everything has some sort of "sell-by" date. You want to pull the old stock to the front as part of rotation and you want to pull expired stuff entirely to avoid lawsuits of the variety you get when someone dies of botulism from an out-of-code can of green beans.
Sure, a casual scan is sufficient for daily operations, but considering how automated equipment generally works, it's entirely likely that a full scan might be just as efficient as a human's casual inventory. If all you want to do is fill holes, that is also something that can be easily automated. Tack it on to the algorithm that spots the misplaced package of bacon.
But the grocery business is very low margin to begin with. And this is after all, the Age of the Bean Counter where nothing less than 110% efficiency will do, so anything that keeps reality and the database aligned is going to be popular.
Of course, all I've mentioned so far is based on automating how existing things are done. An automated store might have palletized shelves that are rotated in and out as a unit. Kind of like the Wal-Mart of the future where self-driving trucks back up to the store, automated tow-motors pull display pallets off and place/unwrap them, and the only remaining human employees are the file of security guards that check your bags and receipt every 3 feet from the self-service register to the door.
Are the EMET service providers called EMETICS?
Items on shelves =/= items stocked - items sold. There's breakage, pilferage, accidental checkout of 2 items stuck together and other things beside. Only an actual physical reconciliation can ensure that reality matches what the computers "know".
In my local store, people periodically run the aisles looking for misplaced items. When they find one, they toss it in a cart and go on until they've run the aisles. Then they sort the cart, reshelve the non-perishables, and dump the hamburger that was found next to the soft drink aisle after sitting for who knows how long.
The hardest part of this is the recognition, and machine vision is more than adequate for most of this these days even on a Raspberry Pi, I think. You would have to be a bit creative to do the sorting, especially if the picker has scooped up a few toddlers, but likely a single machine would be able to handle a whole store's worth of items.
Because the items in question are presumably not Open Source, they're
closely guarded product security secrets
Meaning that the open-source support community hasn't had a chance to vet these resources for either accidental security holes, deliberate back doors, or weak spots that this quarter's budget didn't allow fixing.
So an unfriendly power can see things that the American public cannot see, giving them an advantage in terms of exploits and exploit counter-measures.
Facts are deadly to any form of ideological purity. The world is a complex place and no one-size-fits-all solution exists.
The stock answer to why we have to keep feeding tax cuts to the 1% is "temporarily embarrassed millionaires", despite the obvious fact that very few people even ever become millionaires - much less billionaires. Or the stats that say that your best chances of being rich are by having rich parents.
But I suspect a lot of it has to do with a steady propaganda campaign that it's the Eevil Libruls who raise taxes and all they want to do is steal your hard-earned money and give it to illegal immigrants and lazy undeserving poor people. We all know, after all, that you're only poor if you're lazy and waste your money on drugs and avocado toast.. And besides, Libruls hate Freedom and would give our proud country to the Russians in a heartbeat if they weren't kept in check.
I used to be in the 30% tax bracket and lived in financial security. Nowadays I pay 8% and almost every dime goes into savings for the next time I and my co-workers get laid off. That particular lifestyle gets old. Not to mention interferes with my ability to overcome my millionaire embarrassment.
covfefe
Discovery of the infection came on Sunday, more than five weeks after the onset of the NSA-derived ransomware worm
Seriously, WTF were they playing at not applying the security fixes that were released within days of WannaCry.
OK, so with MS's history it pays to be careful and test each fix before widely deploying it, but 5 fucking weeks ??
"Lost" computers that don't get maintenance, misplaced priorities, lots of reasons.
That's why to this day I still register several of the original SQL server attacks on my domain, even though I don't run SQL server. Someone out there is hoping to get lucky. Sometimes they do.
By then, the rest of the world will have converted to green technology. Locally, having exhausted all our coal and with no technology to speak of thanks to decades of anti-science, limited education, and dirty energy, we'll have plenty of job opportunities - for charcoal burners. Assuming we haven't also clear-cut all the forests by then.
Damn those Democrats! Even when they're the minority party they still rule the whole country!
...and so were cellular telephones when they first came to market. All that you needed was a scanner.
In fact, it was perfectly legal under the Communications Act of 1934 to listen to - but not repeat - communications received in any mode on any frequency.
Then Reagan Got The Government Off The Backs Of The People and signed a law that made it not merely illegal to receive cellular communications, but to sell radios capable of receiving cellular communications. Land of the Free.
Not that it did much good. Cellphones of the day tended to leak over onto my police-band radio anyway. And technically whoever blew up Newt Gringrich's reign by publishing a cell call intercepted in Gainesville, Florida should have been prosecuted, but no one was.
These days, however, more communications than not are both digitized and encrypted. That includes the public-service stuff like fire departments, public transportation, routine police work and a lot more. You can no longer hear what you're paying for or how your local/state government does its day-to-day work.
Sigh. Make me work for a living.
It's always best to do one's own research, as it helps to avoid being fed cherry-picked reality. But, if you insist, here's some stuff I cherry-picked from Google.
The first one is very interesting because it dates all the way back to 1998, when JIT Java was fairly new, but the relative timings are quite comparable, given similar constraints:
http://www.javaworld.com/artic...
Much more recently:
https://benchmarksgame.alioth....
Your Mileage can Definitely Vary, however. I found benchmarks indicating that the "Java" (Don't call it Java or Oracle's lawyers will swarm you - it's Dalvik) on Android is significantly slower.
Some of my own impressions of relative performance are dated, I think. The Gnu compilers have added some very aggressive optimizations in recent years.
The Debian benchmark seems to indicate that raw C (gcc) is on average about twice as fast as either Java or C++. My suspicion is that a lot of modern C++ coding is not only using virtual methods, but taking advantage of string and dynamic memory managers that were not part of the original C++. There is a cost for using pre-packaged solutions, but in an era where machine time is cheap but programmers still cost $10K a year even in India, shops generally favor "Git 'R Dun" over hyper-optimal performance.
I've always been partial to the definition (I think by Alan Kay) that Java is "C++ without the mace and knives". I find Java to be less stressful because I don't obsess about what raw machine code will be produced, and the rigorous compile-time checking means that I can devote more time to worrying about the high-level design. However, a JVM is a greedy thing, so there are still times when I prefer C or C++. Then again, there are times when I prefer Python, Perl, or PHP.
In the end, it's less about language and more about intelligent design. I once encounted a perfectly horrible C++ program that used a very sparse array with a widely-distributed working set. Virtually every computation triggered a page fault; I've seen cases where "efficient" sorts and searches were totally unsuitable because the data was in worst-case form. For performance, the choice of language is less important than how it's used. And above all, measure instead of simply "knowing".
The reason why I take such umbrage against the "common knowledge" that Java is slow is because that knowledge is largely based on old-time interpreter implementations, where on average, an interpreted instruction would take about 10 times longer than its native-code equivalent because a lot of the code being executed wasn't the app, it was the interpreter. JIT-compiled code has no interpreter overhead, so it's primarily limited by the optimization capabilities of the JIT compiler and the tuning settings (small code, slow code vs. fat code, fast code, for example). For lightweight apps, the overhead of launching a JVM, to say nothing of the overhead of doing the JIT compiling is obviously not worth it. For something that launches, runs 24x7 and doesn't restart for weeks at a time, those considerations are fairly trivial - assuming there's enough RAM. If you have dynamic load-balanced re-compiling, then the overall performance is likely to be better than for a static-compiled app.
But juggling instructions tends to only give you about an extra 10% boost, and on the whole, I prefer enough headroom for that not to matter. What makes or breaks most systems is the app itself. I knew of one where a single switch setting could single-handedly bring an IBM mainframe to its knees if set improperly. No compiler in the world could have helped that.
You have the right intuition, but intuition is dangerous. It's true. For really, really short one-shot code segments, the overhead of launching a Java VM is ferociously expensive, much less running monitor functions. Might as well crack walnuts with a hydraulic press.
However, as you scale up, the overhead remains more or less fixed and becomes less and less of a percentage of the overall workload. If your optimization mechanisms are any good, you eventually reach a tipover point where the overhead more than pays for itself. The benefits mostly show up in long-running and frequently-executed processes which are usually what you find in servers and the bulk of the JVM optimization functions are geared towards that environment.
I'm not in the gaming industry, but I would be cautious about a flat assertion that all games are written in C++. At least at one time, I think that there were some gaming-specific programming languages and some development environments that were designed specifically for game functions and have had years to get tuned even without machine assistance. Moreover, I think it unlikely that games are going to see a lot of shifting workloads - although that's more of a "know" thing than a measured fact - and repeated dynamic recompilation isn't necessary or useful in such cases.
I do know of one game that definitely is written in Java: Minecraft for the Raspberry Pi. The Pi is not a powerful computer by modern standards, so running Java, much less a computer game in Java on it is no small accomplishment. I've worked with mainframes that couldn't host a JVM. OK, they were really old mainframes, but still....
The conceit from the knee-biter crowd that Java is slow needs to die. I've worked with video editors, complex GUI design apps and IDEs (both Eclipse and the Arduino IDEs are Java apps) and never felt the difference between Java-based products and products written in other languages. I'm not saying that Java is the solution for all problems.
I'm not into one-size-fits-all. Leave that to the religious and political crazies. I use Java, Python, assembly language, even Fortran and COBOL, LISP, Perl and more, depending on what works best for the problem at hand. I'll happily defend any of them, and I hope I'd be just as happy to admit their respective flaws. Because if you cannot admit flaws as well as strengths, you're an ideologue and an ideologue is just an idiot with an agenda.
thus, like Java, can potentially run faster than static-compiled programs.
And yet, it never actually does.
Because you "know" it can't.
Some of us have seen actual numbers and benchmark code.
I optimize for a living and one of the first things you learn when you go to boost performance is to get hard measurements and to never, ever optimize prematurely.
Because the bottleneck is almost never where you "know" it's supposed to be.
You could start a major flame war on the subject of C++ templating. It's a powerful tool, but it's very easy to cut yourself.
Actually, if you want really strong compile (and run) time checking, the winner is Ada. It not only rigorously enforces type conformance, it also asserts domain and range validation on everything. If I define a type in ADA named POSITIVE_INTEGER and give it a domain of 1..INFINITY, assigning a negative number or zero stops the whole game on the spot.
Please don't ascribe the virtues of an IDE to a language. There is a Python plugin for the Eclipse IDE (actually more than one, I think), though offhand, I cannot recall what, if any popup help you get.
Java does have the advantage that the language is designed to be auto-documented, and that information is easy to feed to an IDE. Python tends that way, but since it doesn't keep as tight a rein on things, I don't know how much IDE support is presently available.
JIT-compiling these days [...] potentially run faster than static-compiled programs
Argh, not this phrase again... potentially but never really.
Existing Benchmarks beg to differ. There are hard numbers if you care to look them up.
YMMV, of course. A one-shot run of code may or may not run faster. One of the advantages of dynamic systems, however, is that for large-scale computations, it becomes economical to statistically analyse the code and alter it based on workload. Even in ancient times you could often gain a significant speed boost by flipping a test so that the most common instruction path did not branch or switching what working data was kept in registers. On modern processors, you can play all sorts of games by reducing bubbles in the instruction pipeline, optimizing register and cache usage, and so forth.
Using a dynamic recompilation process you can optimize on the fly to a degree that would be cost-prohibitive, if not impossible to achieve via hand optimization, and unlike static compiler systems, you can do it without stopping the process and restarting it. It's the real-world equivalent of being able to change tires on a Formula 1 race car without it ever having to slow down for a pit stop.
All true, but the question was written in a future tense: "Will Python...???". What holds true today need not hold true tomorrow. It didn't for Java, after all.
That, and the fact that python is horribly slow.
So was Java, once. Python has JIT-compiling these days, and thus, like Java, can potentially run faster than static-compiled programs.
What Python doesn't have is strong type enforcement. Unless you pre-compile the whole app, entire source files could be filled with monkey-typed gibberish and until the fateful day came that the defective modules were referenced (say, once a Leap Year), they'd be serpents in the grass.
Even pre-compiling won't help if there are insufficient cues to ensure that you won't be passing a dingus to a module that expects to use a wackdoodle.
One printout is just as unconvincing as another. The thing that brought down Dan Rather was that in his case the computer printout in question used anachronistic fonts. But an email dump with full headers can be cross-referenced back to its sources, even if you have it replicated by monks on an illuminated manuscript.
The important thing here is that the original printer isn't going to be made accessible to people trying to confirm the truth of the leaks - only to people trying to trace them.
Long before laser printers, investigators were tying people to typewriters based on unique per-unit imperfections and wear patterns. You can do something similar based on drum and toner distribution variances even on a monochrome non-watermarked printer.
Granted, the judas dots also report the date and time, which helps nail a culprit on a shared resource, but the safest thing to do would be to OCR the printed documents rather than photocopy them.
That "whoosh" over your head was not an Airbus!