Too many people assume that US law applies everywhere. Just because terms like "patent" and "copyright" are common amongst many nations of the world does not mean they follow the US interpretation.
Just look at Canadian's enshrined right to make backups vs. the US DMCA for an example.
I'd fire a developer who didn't apply the security patches and updates for technology in a timely fashion, especially tools that get installed on the client machines.
What's the point of testing to a dot release that is obsolete? You're just going to get complaints from the users running the new software after release and end up looking like you shipped a shitty product.
Whether police or not, government agencies often turn a willfully blind eye to licensing requirements. For some perverse reason, they think that because they're government they can do whatever they want.
Here's a clue for government agencies: You're subject to the same laws and restrictions as citizens, and then some, not less.
The last banking error I had to deal with took less than 48 hours to fix.
But Canadian banks aren't allowed to delay the repair process so they can keep lending out YOUR money while they "fix" the problem as they do in the US.
The last US based bank problem I had took a month to fix; it was the same problem I had here in Canada -- an incomplete/invalid transaction that "withdrew" money from my account but didn't properly "deposit" it with the retail store, leaving insufficient funds to retry the transaction.
Until you're stuck trying to debug the memory leak in your C/C++ code because the server won't run more than 2 hours without barfing.
The best solution is to be language agnostic and use what is best suited for the task at hand. Unfortunately most companies are more interested in a one-language-fits-all approach nowadays because they think it "simplifies" the system and reduces the complexity. Unfortunately, once you start implementing workarounds for language constraints, you soon realize that big complex systems require big complex code no matter what language is used.
It's just a matter of which complexity vs. functionality trade-offs you're willing to eat with your project budget. You can have a million lines of C code full of function pointers and struct overlays that is hard as hell to understand and debug; you can have 100,000 lines of C++ code that generates inferred objects from templates without your control producing a binary as big as the million lines of C; or you can have 50,000 lines of Java that eliminates the majority of constructor/destructor code that is the most common cause of memory leaks.
Any one of the above will do the job. The question is what skillsets do you have available and how much time do you have to deal with the inevitable bugs that creep in no matter which language/approach you've chosen.
Choose wisely. Because when the bugs inevitably arise, proponents of some other language or framework will be quick to roast you and try to have you turfed as incompetent for making a different choice than they would have. Not a "wrong" choice, but a different one.
I find it endlessly amusing that the only "new" tool in that list is Ruby (and even that's been around a few years.)
Particularly in light of yesterday's Bloomberg article claiming that the income and job pressure on senior developers is because they weren't trained in the "new tools." It looks to me like marketshare demonstrates companies are more interested in stable technology than new technology.
I'm not surprised Java is sliding, though. It's really become a server-centric language over time, which means there are far fewer deployments per customer than there are for the client-side components of the whole system, such as C# and Objective C++ clients that access those Java servers.
Still, I'm quite comfortable continuing my Java development work. My focus in computing life has always been the server, though I did spend several years on client-side programming as well. While client-side GUI programming is fun, it's also far more time consuming and tedious. I find server-side coding and the performance tuning aspects of it are far more entertaining and challenging. (You can write shitty client code and get away with it because the load is distributed, but if you write shitty server code you have thousands of cranky users, not just a few who's devices are underpowered.)
You don't grasp that complex systems interact on multiple levels? That there are cascading effects from one subject group to another? That changing one piece of this complex "function" causes other values to change?
I guess I forgot one other thing about senior programmers: They have a much firmer grasp on the reality of complex, interdependent business solutions and interactions than juniors and intermediates who think problems and errors with their system occur in isolation rather than causing cascading data problems.
I'd think it would be easy enough for cell contracts to have opt-in pre-authorization signatures for releasing 911 call information, rather than scrapping the idea that warrants are needed for all non-911 requests.
Personally I don't understand why the telcos should care whether a warrant is required or not. That's up to the legal system to determine on behalf of the PEOPLE, not for corporations to decide. The law is about protecting PEOPLE, not what's "easiest" for corporations.
For some people like me, cannabis really is a miracle cure. Maybe not the cure-all that some claim, but for migraine management it has no peer.
It take 5 minutes to get complete symptomatic relief by using indica-dominant cannabis: no auras, no nausea, no pain, no light-sound-odour sensitivity. And it works all the time.
Compare that to triptans, "modern medicine" for migraines that manipulate seratonin levels. They take 30-45 agonizing minutes to be absorbed by the stomach. They only work 40-50% of the time, giving you no relief at all the rest of the time. And when combined with SSRIs by accident, they cause a severely dangerous condition called "seratonin syndrome" which can not only cause brain damage and bi-polar or full scale schizophrenia permanently, seratonin syndrome can even be fatal.
As someone who has suffered seratonin syndrome damage, I say unequivocally and with no room for debate:
Cannabis is the superior tool for managing migraines.
Guess what? Between JEE servlets and JSPs, ASP.Net, and the various Apache libraries, I've never had to touch a line of PHP code in my life.
Contrary to the belief of fanatics for different tools and technologies out there, it is very possible for other people to spend decades writing code without ever touching your favourite tool or technology.
Personally I believe the bigger issue is the pressure offshoring has put on the market.
The jobs that used to be handled by junior programmers are now offloaded to offshore service providers. So the junior programmers, who just happen to have played with the latest toys and tools while we were busy writing useful code with the previous generation of tools, are readily available at a cut throat price.
So the work that used to be handled by the intermediate programmers now gets passed off to the new grads who used to be the juniors. In the meantime, the intermediate programmers are now ready and willing to undercut the senior programmers for their former job of designing systems and collecting requirements. Sure they don't have the experience of the senior programmers, but they're cheaper, so they get the job.
Which leaves the senior programmers on the short end of the stick. Thanks not only to the pressure of offshoring but the increased use of effective template-based designs, tooling, and frameworks that put to shame older tools like CORBA, and suddenly the only experience the senior programmer has that's actually relevant is their business experience.
Their degree is out of date. Their tools are matured with a wide range of skillsets available for reasonable or cheap prices.
But one thing experience teaches you that nothing else can is an intuitive grasp of how the frameworks and tools function and what they are probably doing inside all that obfuscated and hidden code. Because we used to have to write the code the frameworks implement by hand.
Unfortunately, despite the speed with which senior developers can debug problems thanks to their intuitive grasp of "the machine", there just aren't enough "tough" debugging problems to justify keeping them around in anything but the largest of teams and companies.
Still, senior developers can find work. If they're willing to retool, retrain, move, and take a pay cut that may well mean they're making less in real, spendable dollars than they did twenty years ago. And if they're real, real lucky.
You mean cons like pollution of the ground water, causing minor earthquakes, and being left with hundreds of thousands or millions of gallons of polluted material that you need to do something with?
If we spent a tenth of what we do on exploration and "extraction technology" on the development of bio-diesel crops such as cannabis and canola, we'd not only free ourselves from dependency on oil and gas reserves, we'd be using a fuel that actually consumes CO2 during it's growth phase.
Some even claim that hemp-based bio-diesel is carbon negative when you consider the full production cycle, and I'd dearly love to see that theory tested.
From what I've read of this film so far, the grad students involved would have been better served if they had worked with the experts in the field: the drama department.
Why is it that so many "geeks" think they're good at everything just because they're experts in one or two fields? No one is good at everything, so sometimes you need to swallow your pride, shelve your ego, and call in people who are experts.
The limitations on the hardware sprites were why many C-64 games used software sprites for "characters", reserving the hardware sprites for "bullets" in most cases, and relying entirely on software to do the collision detection.
So although the C-64 had more "advanced" sprite hardware, in practice it wasn't used by anything but the simplest and most basic of arcade shooter games.
Hell, you couldn't even program Space Invaders using the hardware sprites, and that's about as basic as a game could get!
Actually if you look into the BASIC interpreters of the time, I can't think of a single one that actually stored entire keywords in memory. They used codes for keywords and variables, such that most keywords were encoded as a single byte.
The Sinclair just made it possible to TYPE those codes explicitly instead of having to spell out the words and let the interpreter do the primitive compression.
In particular, I'm thinking of Commodore's implementation and the TRS-80.
I have no problem paying $100 for a video game that provides me with 100+ hours of entertainment, and that is the problem with a lot of games. Price is no guarantee of quality, unfortunately.
But that's the key reasons that people sell used games nowadays. They don't have the replayability of a lot of older games, especially the "shooter on rails" type games. And aside from replay value, the initial play-through of the single-user game is often a matter of 5-20 hours with modern games, whereas 40-60 hours was typical even in the '90s.
If I've bought and played through a game that isn't fun to play again, you can bet your sweet patoot I'm going to sell it off for whatever I can get rather than keep it. I only keep games that are fun and worth playing again.
If I do find myself in possession of a game not worth keeping and that I want to sell off, you can also bet I am not happy with the publisher and that I'm feeling ripped off by them. I'm far less likely to buy any other products from them in the future not because of used game competition, but because they ripped me off.
The problem I see is in the definition of "jerk". Had someone from the general public joined one of our LAN parties years ago and heard us yelling and cursing each other out, they would have thought us rude, boorish, and nasty people.
But we weren't nasty. We were friends having fun, complete with the insults and slams that go on in my circle of friends. People who joined us occasionally knew that and didn't take offense at our behaviour, but the general public would have.
Now mind you, when we played on public servers instead of the office server, we shut our traps and stopped insulting everyone. We understood the difference between playing in public and playing in private.
Not true. The Dalvik compiler was used to compile the GPL-released Java library/package source. Google did not rewrite all of Java, just a non-JVM runtime/virtual-machine (and even that came from an Apache project.) Either Google has a proprietary license to do so (which they don't), or they had to rely on the GPLv2 licensed Java source that Sun released before Oracle bought them.
Unfortunately I couldn't find any articles speaking to GPLv2 compatibility, only v3.
I thought part of the argument was around features such as introspection, and some variables/constants in the APIs that Google would have had to pull from the Java GPL source in order to build Dalvik in a compatible fashion. Though to be honest, I can't imagine what constants those might possibly be seeing as Dalvik doesn't try to provide byte-code compatability so it could use whatever constants and structures it chooses for implementation, regardless of how the "official" Java does it.
And now I can understand why Oracle's shorts are in a knot.
A key point of Java technology is the cross-platform nature of the JVM. Without the JVM, you lose the portability that was a primary goal, and which Sun fought Microsoft to protect. Microsoft, despite having licensed Java, was beaten down in court for their "variant" on Java.
Regardless of the legalities of the case, I now have to take Oracle's side on the issue. Google is breaking the Java "contract" with developers: portability. Java is not just the syntax and libraries; it's the whole ecosystem, including the concept of portable jars. So regardless of the finer points of law that have been brought up, I hope Oracle wins.
Slashdot Mirror
Bullshit. I spent over 12 years on C++ projects. Everyone screws up something, somewhere, sometime.
I've since spent almost 15 years with Java.
Guess what? Java is a hell of a lot easier to debug.
I've done more cross-language support with C code and C++ wrappers than you can ever grasp with your feeble little mind.
+10 if I had the points.
Too many people assume that US law applies everywhere. Just because terms like "patent" and "copyright" are common amongst many nations of the world does not mean they follow the US interpretation.
Just look at Canadian's enshrined right to make backups vs. the US DMCA for an example.
Funny.
I'd fire a developer who didn't apply the security patches and updates for technology in a timely fashion, especially tools that get installed on the client machines.
What's the point of testing to a dot release that is obsolete? You're just going to get complaints from the users running the new software after release and end up looking like you shipped a shitty product.
Which you did.
Whether police or not, government agencies often turn a willfully blind eye to licensing requirements. For some perverse reason, they think that because they're government they can do whatever they want.
Here's a clue for government agencies: You're subject to the same laws and restrictions as citizens, and then some, not less.
The last banking error I had to deal with took less than 48 hours to fix.
But Canadian banks aren't allowed to delay the repair process so they can keep lending out YOUR money while they "fix" the problem as they do in the US.
The last US based bank problem I had took a month to fix; it was the same problem I had here in Canada -- an incomplete/invalid transaction that "withdrew" money from my account but didn't properly "deposit" it with the retail store, leaving insufficient funds to retry the transaction.
Until you're stuck trying to debug the memory leak in your C/C++ code because the server won't run more than 2 hours without barfing.
The best solution is to be language agnostic and use what is best suited for the task at hand. Unfortunately most companies are more interested in a one-language-fits-all approach nowadays because they think it "simplifies" the system and reduces the complexity. Unfortunately, once you start implementing workarounds for language constraints, you soon realize that big complex systems require big complex code no matter what language is used.
It's just a matter of which complexity vs. functionality trade-offs you're willing to eat with your project budget. You can have a million lines of C code full of function pointers and struct overlays that is hard as hell to understand and debug; you can have 100,000 lines of C++ code that generates inferred objects from templates without your control producing a binary as big as the million lines of C; or you can have 50,000 lines of Java that eliminates the majority of constructor/destructor code that is the most common cause of memory leaks.
Any one of the above will do the job. The question is what skillsets do you have available and how much time do you have to deal with the inevitable bugs that creep in no matter which language/approach you've chosen.
Choose wisely. Because when the bugs inevitably arise, proponents of some other language or framework will be quick to roast you and try to have you turfed as incompetent for making a different choice than they would have. Not a "wrong" choice, but a different one.
"whose devices", not "who's devices" :P
-- The self-deprecating grammar nazi
I find it endlessly amusing that the only "new" tool in that list is Ruby (and even that's been around a few years.)
Particularly in light of yesterday's Bloomberg article claiming that the income and job pressure on senior developers is because they weren't trained in the "new tools." It looks to me like marketshare demonstrates companies are more interested in stable technology than new technology.
I'm not surprised Java is sliding, though. It's really become a server-centric language over time, which means there are far fewer deployments per customer than there are for the client-side components of the whole system, such as C# and Objective C++ clients that access those Java servers.
Still, I'm quite comfortable continuing my Java development work. My focus in computing life has always been the server, though I did spend several years on client-side programming as well. While client-side GUI programming is fun, it's also far more time consuming and tedious. I find server-side coding and the performance tuning aspects of it are far more entertaining and challenging. (You can write shitty client code and get away with it because the load is distributed, but if you write shitty server code you have thousands of cranky users, not just a few who's devices are underpowered.)
You don't grasp that complex systems interact on multiple levels? That there are cascading effects from one subject group to another? That changing one piece of this complex "function" causes other values to change?
I guess I forgot one other thing about senior programmers: They have a much firmer grasp on the reality of complex, interdependent business solutions and interactions than juniors and intermediates who think problems and errors with their system occur in isolation rather than causing cascading data problems.
I'd think it would be easy enough for cell contracts to have opt-in pre-authorization signatures for releasing 911 call information, rather than scrapping the idea that warrants are needed for all non-911 requests.
Personally I don't understand why the telcos should care whether a warrant is required or not. That's up to the legal system to determine on behalf of the PEOPLE, not for corporations to decide. The law is about protecting PEOPLE, not what's "easiest" for corporations.
For some people like me, cannabis really is a miracle cure. Maybe not the cure-all that some claim, but for migraine management it has no peer.
It take 5 minutes to get complete symptomatic relief by using indica-dominant cannabis: no auras, no nausea, no pain, no light-sound-odour sensitivity. And it works all the time.
Compare that to triptans, "modern medicine" for migraines that manipulate seratonin levels. They take 30-45 agonizing minutes to be absorbed by the stomach. They only work 40-50% of the time, giving you no relief at all the rest of the time. And when combined with SSRIs by accident, they cause a severely dangerous condition called "seratonin syndrome" which can not only cause brain damage and bi-polar or full scale schizophrenia permanently, seratonin syndrome can even be fatal.
As someone who has suffered seratonin syndrome damage, I say unequivocally and with no room for debate:
Cannabis is the superior tool for managing migraines.
Guess what? Between JEE servlets and JSPs, ASP.Net, and the various Apache libraries, I've never had to touch a line of PHP code in my life.
Contrary to the belief of fanatics for different tools and technologies out there, it is very possible for other people to spend decades writing code without ever touching your favourite tool or technology.
Personally I believe the bigger issue is the pressure offshoring has put on the market.
The jobs that used to be handled by junior programmers are now offloaded to offshore service providers. So the junior programmers, who just happen to have played with the latest toys and tools while we were busy writing useful code with the previous generation of tools, are readily available at a cut throat price.
So the work that used to be handled by the intermediate programmers now gets passed off to the new grads who used to be the juniors. In the meantime, the intermediate programmers are now ready and willing to undercut the senior programmers for their former job of designing systems and collecting requirements. Sure they don't have the experience of the senior programmers, but they're cheaper, so they get the job.
Which leaves the senior programmers on the short end of the stick. Thanks not only to the pressure of offshoring but the increased use of effective template-based designs, tooling, and frameworks that put to shame older tools like CORBA, and suddenly the only experience the senior programmer has that's actually relevant is their business experience.
Their degree is out of date. Their tools are matured with a wide range of skillsets available for reasonable or cheap prices.
But one thing experience teaches you that nothing else can is an intuitive grasp of how the frameworks and tools function and what they are probably doing inside all that obfuscated and hidden code. Because we used to have to write the code the frameworks implement by hand.
Unfortunately, despite the speed with which senior developers can debug problems thanks to their intuitive grasp of "the machine", there just aren't enough "tough" debugging problems to justify keeping them around in anything but the largest of teams and companies.
Still, senior developers can find work. If they're willing to retool, retrain, move, and take a pay cut that may well mean they're making less in real, spendable dollars than they did twenty years ago. And if they're real, real lucky.
Neanderthal.
Good comeback.
Very insightful argument.
It adds a lot to your position.
Clearly the next step is to have server maintenance done by the volleyball team. And the basketball team can handle the campus networks. :P
I like to think of bio-diesel as the most effective and practical means of storing solar energy that there is.
You mean cons like pollution of the ground water, causing minor earthquakes, and being left with hundreds of thousands or millions of gallons of polluted material that you need to do something with?
If we spent a tenth of what we do on exploration and "extraction technology" on the development of bio-diesel crops such as cannabis and canola, we'd not only free ourselves from dependency on oil and gas reserves, we'd be using a fuel that actually consumes CO2 during it's growth phase.
Some even claim that hemp-based bio-diesel is carbon negative when you consider the full production cycle, and I'd dearly love to see that theory tested.
From what I've read of this film so far, the grad students involved would have been better served if they had worked with the experts in the field: the drama department.
Why is it that so many "geeks" think they're good at everything just because they're experts in one or two fields? No one is good at everything, so sometimes you need to swallow your pride, shelve your ego, and call in people who are experts.
The limitations on the hardware sprites were why many C-64 games used software sprites for "characters", reserving the hardware sprites for "bullets" in most cases, and relying entirely on software to do the collision detection.
So although the C-64 had more "advanced" sprite hardware, in practice it wasn't used by anything but the simplest and most basic of arcade shooter games.
Hell, you couldn't even program Space Invaders using the hardware sprites, and that's about as basic as a game could get!
Actually if you look into the BASIC interpreters of the time, I can't think of a single one that actually stored entire keywords in memory. They used codes for keywords and variables, such that most keywords were encoded as a single byte.
The Sinclair just made it possible to TYPE those codes explicitly instead of having to spell out the words and let the interpreter do the primitive compression.
In particular, I'm thinking of Commodore's implementation and the TRS-80.
No comments yet, and the server is already slashdotted...
It must be running on one of those old beasties. :P
But that's the key reasons that people sell used games nowadays. They don't have the replayability of a lot of older games, especially the "shooter on rails" type games. And aside from replay value, the initial play-through of the single-user game is often a matter of 5-20 hours with modern games, whereas 40-60 hours was typical even in the '90s.
If I've bought and played through a game that isn't fun to play again, you can bet your sweet patoot I'm going to sell it off for whatever I can get rather than keep it. I only keep games that are fun and worth playing again.
If I do find myself in possession of a game not worth keeping and that I want to sell off, you can also bet I am not happy with the publisher and that I'm feeling ripped off by them. I'm far less likely to buy any other products from them in the future not because of used game competition, but because they ripped me off.
The problem I see is in the definition of "jerk". Had someone from the general public joined one of our LAN parties years ago and heard us yelling and cursing each other out, they would have thought us rude, boorish, and nasty people.
But we weren't nasty. We were friends having fun, complete with the insults and slams that go on in my circle of friends. People who joined us occasionally knew that and didn't take offense at our behaviour, but the general public would have.
Now mind you, when we played on public servers instead of the office server, we shut our traps and stopped insulting everyone. We understood the difference between playing in public and playing in private.
Not true. The Dalvik compiler was used to compile the GPL-released Java library/package source. Google did not rewrite all of Java, just a non-JVM runtime/virtual-machine (and even that came from an Apache project.) Either Google has a proprietary license to do so (which they don't), or they had to rely on the GPLv2 licensed Java source that Sun released before Oracle bought them.
Unfortunately I couldn't find any articles speaking to GPLv2 compatibility, only v3.
I thought part of the argument was around features such as introspection, and some variables/constants in the APIs that Google would have had to pull from the Java GPL source in order to build Dalvik in a compatible fashion. Though to be honest, I can't imagine what constants those might possibly be seeing as Dalvik doesn't try to provide byte-code compatability so it could use whatever constants and structures it chooses for implementation, regardless of how the "official" Java does it.
And now I can understand why Oracle's shorts are in a knot.
A key point of Java technology is the cross-platform nature of the JVM. Without the JVM, you lose the portability that was a primary goal, and which Sun fought Microsoft to protect. Microsoft, despite having licensed Java, was beaten down in court for their "variant" on Java.
Regardless of the legalities of the case, I now have to take Oracle's side on the issue. Google is breaking the Java "contract" with developers: portability. Java is not just the syntax and libraries; it's the whole ecosystem, including the concept of portable jars. So regardless of the finer points of law that have been brought up, I hope Oracle wins.
If Microsoft can be bitch-slapped, so can Google.