Any algorithm can be execed on any Turing complete language. ANYTHING you can write in C you can write in java and vista versa in terms of an algorithm.
False. You cannot do pointer arithmetic in Java, so algorithms that depend on pointer math must be transformed into a DIFFERENT algorithm.
The end result may be the same for the same input, but the algorithm (the "steps you take to solve the problem") is different.
>blockquote>
My java program is over 5x faster than the C one it replaces and it uses less memory for a given problem and it doesn't segfault with bad arguments. Facts just doesn't seem to matter you "C is the fastest" facktards.
>/blockquote>
Not my fault you can't write decent c code.
BTW - you might want to look at what language your JVM was implemented in. Hint - it wasn't Java. Second hint - it was c.
Yes, multi-threaded is harder, but you get used to it, like anything else. And then, like anything else, you get a gut instinct as to where you or someone else screwed up, just by the way the code is reacting.
If it were easy, everyone would be doing it. But the performance benefits of not needing things like reference counts, garbage collectors, etc., make it worth it. After all, you fix the problem once, and reap the benefits the billions of times that code executes.
If we were to truly cost out the cost of inefficient code (energy consumption, increased hardware requirements, etc.) I think we'd pay more attention to optimizing code, and programming languages that allow you to work at a lower level.
Picture a multi-threaded app that is written in language X. It runs fine on a single core, until a certain point, where it now has to use a second core. Everything slows down, because now you have to synchronize across cores - a much slower process, and you pollute the cache a lot more. Even worse if it's across external cpus - time for a rewrite. So an app that was running 500 requests a sec on one core is only able to run 750 on two cores, 900 on 3 cores, 1050 on 4 cores, etc., nowhere near linear scaling.
Now re-implement it in language Y that uses fewer resources, runs quicker out of the box, etc. It runs 1,000 requests a second on one core, 1500 on two cores, 1800 on 3, and 2100 on 4. But since you're now working at a lower level, you can cheat a bit, and you manage to pick up a further 10% speed increase.
So while language X now needs a second quad-core box, and maxes both of those out at less than 2000 requests/sec, language Y is running fine on a single box, and individual requests are still served much quicker from start to finish
Multiply that scenario by a million redundant servers, plus electricity, ac, space, management, etc, to begin to understand what inefficient languages really cost us all. A billion here, a billion there, and soon you're talking real money!
Well, it didn't take over the desktop; but it did take over the server
The servers that it did take over are now directly threatened (as are the database servers that they communicate with via java) by map-reduce and nosql. Much more scalable, no dependence on Oracle for anything, runs fine on commodity hardware, much easier to synchronize as well as build in transaction isolation and rollback.
10 years. That's an eternity in internet time, but not in human time, and the continued growth of data stores and rising energy costs make it not only possible, but inevitable.
And THIS is just one exampe of how Java is overly verbose. You still end up creating a bunch of "glue" that's simply not needed with pointers to functions and/or jumps to a function at offset PTR_BASE+(mode*PTR_SIZE);
Just enum RED_LIGHT=0, YELLOW_LIGHT, GREEN_LIGHT then either jump to the offset at LIGHT_FUNCS+light*PTR_SIZE, or if you've created an array of function pointers, set lights[NORTH_SOUTH] = light_funcs[light]; Your code becomes more generic, even though the code for handling a red light may be completely different than the code for a green light, which may, for example, refuse to set itself to green if lights[EAST_WEST] is still green, setting the function lights[NORTH_SOUTH] pointing back to light_funcs[RED_LIGHT], and return, rather than a whole bunch of trys, cases, ifs, and exception handlers.
The best part is that you can now tie this (by using the volatile keyword) into a real-time external process that changes one byte of ram. Set up a thread to check that address every second and you've got your light controller for that street corner.
Need to expand it to 10,000 street corners? Not a problem - your total memory requirements only grew by 2*sizeof(ptr), plus 2 byte for light state (000=both_blinking_red, 001=both_red, 010=nsgreen, 011=ewgreen, 100=nsyellow, 101=ewyellow) and seconds_elapsed (a 13-bit integer - good for more than 2 hours); Even on 64-bit systems, the whole 10,000 light controller (data and code) would fit into well under 200k. On a 16-bit system it could probably be shoe-horned into 64k (in this case it's the pointers that eat up the space on 64-bit systems - 20,000 pointers only take up 40k on 16 bits).
There's no way you'd ever get that to run in 64k under Java - just the run-time takes a LOT more than that.
I think you misunderstood - I wasn't saying hire a contractor as a replacement during the hiring process - "hire a programmer on a contract basis to help them weed out candidates." - and only that.
In other words, come in one afternoon or evening a week, or on a weekend, and sit in on the interviews, then give your opinion on the pros and cons of the candidate.
Certainly a lot better than anything that a recruiting agency will do, and cheaper in the long run.
All that is well and good, but it ignores my key point - the vast majority of IT failures have nothing to do with people's technical skills, but management's failure to communicate. Technical skills can be acquired (and when you're developing new technology, obviously it's the only way to go, since there is no prior art, etc.) - communications skills, obviously not so easily.
The use of extensive testing is an easy way to cover up for the lack of a proper way to assess the more important aspect - is the person a good communicator? Not in the "marketing/powerpoint/bs" fashion, but can they take a concept and teach it to someone else on the team?
Stick them in front of a whiteboard and have them give a talk about something. Did you understand it? If so, they've demonstrated 4 things - that they know it, that they know it well enough to explain it to others, and that others can understand their style of communicating, and that they also know how to listen (more on that in a sec).
15 minutes to a half-hour should be all that's needed. If they wash out on communications skills, then it doesn't matter how hot-shot prima donna they are with code. If they're good communicators, they got that way by listening to others, and adapting their "pitch" to the abilities of their audience.
It's a simple test, with a simple pass/fail standard - did you understand what they were talking about? If they bored the crap out of you, they're a poor communicator. If they kept having to pause for 15 seconds to 1 minute to "fill the pipeline", they're not really on top of the subject matter, so you've also eliminated the "BS-ers".
You also get to see if they're really enthusiastic about what they do, or if it's just a job, so you cover the "desperate for a job" motivation as well - someone who's enthusiastic will easily be able to go beyond the 15-30 minutes. It also lets you see if anyone else in the room is not going to be a good fit, personality-wise, during any Q and A. Do they get into a "pissing match?" If so, who started it, and how did the other person handle it? (You might want to have a "plant" for doing exactly that).
Of course, this is just too simple and obvious, just like using two screens is a simple and obvious way to improve productivity, from secretaries to coders and everyone else, but most companies won't do it.
Fear. They'd rather trust in some mythical scores so that if it doesn't work out they can CYA by saying "the checkboxes looked good." Do we pick our other relationships like that? I hope not - and work is just as much a relationship as any other.
Java is an interpreted scripting language. It's also nowhere near number one - most hosting providers don't even offer it.
And before we get into *that* argument again... Java is no more compiled than converting a word doc to a pdf is "compiling" it. You cannot execute the resulting class files directly - they need to be interpreted by the run-time (originally, they were supposed to be interpreted by a special "Java chip" - "write once, run anywhere" was the exact opposite of the original design goals).
If Sun had had any brains, they would have fixed the slowness of Java by including the ability to compile down to native code. Then they could have arguably had the best of both worlds.
But what do you expect from a project that changed its goals so many times, even in the early years?
Java, because you can't use pointer arithmetic, is going to be slower than the same code in c using pointer arithmetic, because a non-pointer solution is always going to be slower, in any language, even c.
The lack of pointers was the only way that Java could be implemented. Another reason was to keep both the class verifier the garbage collector simple. You can't "prove" code that can point to something different during the actual run. Both these restrictions introduce behind-the-scenes overhead, as well as restricting what you, the programmer, can write.
The lack of first-class functions is also another area where you are restricted in what you can code. You can't just have, say, a nice tight loop that executes a function, and calls address+mode*size_of_pointer_to_function - you need to write a switch or if/else. For things like modal parsers, this makes a difference. No one-line while() or for() for YOU! Your code, which fits nicely into the cpu cache, L1 cache, probably won't in Java, so the performance hit will be huge.
Java will eventually lose ground there as well for several reasons:
energy and speed considerations - runtimes like dalvik offer a 50% speed boost. Native apps offer many times that in some circumstances.
bloat management - the cost of bloat is becoming more apparent as Java fails to scale on the developer side because of early design mistakes.
heterogenous data - Java doesn't do so well there, with the "there's a class for that" model.
#2 is currently the big issue. Once a Java project passes a certain complexity, any "it's simpler in Java" advantage is lost, and the Java language and development environment become a boat anchor.
The problem is that the Javanistas won't admit it - that Java sometimes, beyond a certain size, introduces MORE complexity than lower-level languages that are more flexible. To them, this is "utterly impossible" - but what do you expect from someone who is afraid to even attempt memory allocation. It's not that hard - just do like your mother taught you - put things back when you're finished with them.
In c, it means that you get in the habit of typing free() right after typing malloc(), then asking yourself, where does the free() really belong? Who is going to "own" this memory. If it doesn't fit naturally within that block, you need to make sure that it's taken care of somewhere else. Move the free() there, and paste in a comment as to who frees it.
In c++, it means making sure that every object owns its own resources, or you enforce a contract with any object it serves as a "factory" to, that the recipient will free it, but not both.
It is possible to write leak-resistant (even leak-free) code. It just takes some attention to detail. But at that point, you have a detrministic program, not one whose performance is dependent on when/if a garbage collector decides to do some cleanup - and you can also do away with the whole {smart|weak}_ptr garbage.
Java is still a lot slower than native methods - it's also, unfortunately, so inflexible compared to, say, c, that you can't even consider using some algorithms that c programmers use all the time. That's what happens when you can't do pointer math - you lose a whole class of efficient ways to do things. Ditto for the lack of first-class functions, so no function pointers for you.
Dream on if yo believe that the JIT is competitive. Even if it were able to pre-compile everything to native methods, you still lack some of the essential programming models that people have been using for decades to make things go faster.
in granting the patents, the PTO went beyond what was allowed in a 1980 Supreme Court decision credited with opening up the biotechnology industry, ACLU said in court filings. It has the support of the American Medical Association and the American Society for Human Genetics.
Biotechnology Industry Organization, the trade group of biotech companies that supported Myriad in the case, is reviewing the decision, Stephanie Fischer, a spokeswoman for the group, said.
The judge did throw out claims that the patent office acted outside its authority in granting the patents. The judge said that, were an appeals court or the Supreme Court affirm his decision, the patent office would "conform its examination policies" to the court rulings.
The case is Association for Molecular Pathology v. U.S. Patent and Trademark Office, 09cv4515, U.S. District Court for the District of New York.
Basically, what happened is that the judge decided that, since he was able to toss the patents w/o having to rule on the validity of the USPTOs actions, he was required to ignore that part of the case, Kind of sucks, but once it gets through the appeals process, it will be another fork in the "stupid patents" model.
We already had "slow-scan tv recorders" back in 1972 in Popular Science magazine. You could record a single image on an audio tape cassette in about 20 seconds. And as you can see from the article, it's been around since 1960
Except that Android doesn't run Java classes - it runs dalvik classes. It's like you taking a.doc file and converting it to pdf so that people don't need the Evil Word.
Java's dying anyway. It's a lot slower than dalvik, and Java simply hasn't lived up to its "write once run anywhere" claims. Just like it hasn't lived up to earlier promises to "reinvent the desktop", or before that, to "change the way we use the Internet with applets - remember them - to add interactivity.
What are they going to do when dalvik is extended to run on regular servers, and all those Java support contracts dry up? Just like is happening right now in the mobile space with the multi-fragmented JavaME?. Pretty bad when your core market tells you that the competition already raided your fridge, ate your breakfast and lunch, and took a dump on your supper.
Your resume says NOTHING about who you are, and what you can do. It makes no difference between 20 years experience, and 1 year 20 times. And everyone lies on there resumes.
Keyword matching is the worst - and it's going to cost you candidates.
My resume had zero experience writing multithreaded servers in c, but the place I eventually worked at, their lead was leaving, and they had tried a half-dozen others before they decided to "scrape the bottom of the barrel" by going to an "older" worker - which by their definition was anyone over 30. The code was terrible, the database design sucked, there was no documentation, and it was obvious why the lead had left for greener pastures - it was "fish or cut bait" time. He had milked this job as far as he could.
So, get familiar with the code, study the posix threads docs online, and start fixing the problems. End result was 3 inter-related specialized linux/bsd-hosted servers (depending on -DBSD for make) that can handle a thousand requests a second (including db lookups on the same low-end hardware), never kills off a thread to "reclaim memory" (zero memory leaks, even after running for months at a time), and it does the job.
Only one problem - the code was now stable enough, and clean enough, that I was no longer needed, and the extra delays meant a round of cost-cutting.
The job hunting process since then has convinced me, more than anything else, that most people doing "recruiting" don't have a clue, and that employers aren't willing to take the logical step - hire a programmer on a contract basis to help them weed out candidates.
It's also why I absolutely refuse to hand out a resume. I am *not* my resume, and my resume is not me. If you have a problem, either I can fix it, or I'll tell you that I can't. The main concern really isn't that anyway (studies show that the leading cause of project failure is bad communications, not lack of technical skills).
The 507 patent ()2001) falls to prior art - RoboBoard, bbs that downloaded graphic primitives and let you navigate through a virtual world (never mind just audio-visual data). Also the Space Quest and Kings Quest games, etc.
The 602 and 314 patents "Attention Manager for Occupying the Peripheral Attention of a Person in the Vicinity of a Display Device." is preceded by, among other things, those annoying tickertape displays that have been around for decades, wall clocks for anyone sitting in front of a computer at 4:55 PM, etc.
The 682 patent "Alerting Users to Items of Current Interest." (2004) is anticipated by the flag on your mailbox that lets you know you have mail, your doorbell, TV Guide magazine, the front page of any newspaper sitting at the news stand, etc. And of course, "You have mail".
Maybe this will the the one that finally puts the end to stupid software patents.
For all we know, corporations ARE paying his paycheck.
Just not in the documented, legal way that we're all accustomed to.
I would hope so. Who would be stupid enough to do that for free? Oh wait, he went and admitted he was doing it - we have a WINNER*!!!
(* only for values of "WINNER" meaning "LOSER!". Avoid listening to him while driving, it may cause drowsiness or road rage. Avoid taking on a full stomach, you may toss your lunch. Avoid voting for in the next election - your cable bill will be highter.)
Yeah, not too many companies running their businesses on smartphones.
Motorola, Samsung, LG, HTC, Apple, even Microsoft would disagree with you. And then there's everyone who uses one - take away their Blackberries and watch several governments falter.
Faster? You really don't get it at all. Software execution speed only matters to 0.01% of the population. For most businesses, the bottleneck is(are) the database(s). Now why on earth would anyone spend money to make their applications faster when it's the data access that's killing performance?
You're the one that doesn't get it. Software execution speed matters to everyone. Look at the new smartphone commercials emphasizing how much faster Android is than an iPhone. Additionally, energy costs matter. Java loses there, same as Windows does to linux or bsd.
Also, data access is only one bottleneck, and you can always work around it if you have any smarts and aren't locked into a crappy platform. Any time you can eliminate one bottleneck, you can do more work. Additionally, map-reduce renders relational databases obsolete, as well as removing the bottleneck.
Get real, stop being childish. Everyone is now looking for alternatives to Java because of this lawsuit, and realizing they're locked into a slow bloated platform.
"I've never put it up for sale, and while I *have* had a few unsolicited offers in the past, and out of politeness I *will* look at them, there's been nothing so far to make me change my mind."
You establish:
That you are not officially trying to sell the domain,
That if you respond to an unsolicited offer, it is not necessarily because you want to sell.
As in all negotiations, the person who speaks first loses. Remember that next time you find yourself on a used car lot.
The keyboard usually isn't a problem. Boot up the machine without a PS/2 mouse connected. After Windows is done loading, plug the mouse it. It usually doesn't work until you reboot
No, you're right - it's not the keyboard, it's the PEBKAC- the person who decides to run an OS that can't handle something as simple as a keyboard being unplugged:-)
Slashdot Mirror
False. You cannot do pointer arithmetic in Java, so algorithms that depend on pointer math must be transformed into a DIFFERENT algorithm.
The end result may be the same for the same input, but the algorithm (the "steps you take to solve the problem") is different.
>blockquote> My java program is over 5x faster than the C one it replaces and it uses less memory for a given problem and it doesn't segfault with bad arguments. Facts just doesn't seem to matter you "C is the fastest" facktards. >/blockquote> Not my fault you can't write decent c code.
BTW - you might want to look at what language your JVM was implemented in. Hint - it wasn't Java. Second hint - it was c.
If it were easy, everyone would be doing it. But the performance benefits of not needing things like reference counts, garbage collectors, etc., make it worth it. After all, you fix the problem once, and reap the benefits the billions of times that code executes.
If we were to truly cost out the cost of inefficient code (energy consumption, increased hardware requirements, etc.) I think we'd pay more attention to optimizing code, and programming languages that allow you to work at a lower level.
Picture a multi-threaded app that is written in language X. It runs fine on a single core, until a certain point, where it now has to use a second core. Everything slows down, because now you have to synchronize across cores - a much slower process, and you pollute the cache a lot more. Even worse if it's across external cpus - time for a rewrite. So an app that was running 500 requests a sec on one core is only able to run 750 on two cores, 900 on 3 cores, 1050 on 4 cores, etc., nowhere near linear scaling.
Now re-implement it in language Y that uses fewer resources, runs quicker out of the box, etc. It runs 1,000 requests a second on one core, 1500 on two cores, 1800 on 3, and 2100 on 4. But since you're now working at a lower level, you can cheat a bit, and you manage to pick up a further 10% speed increase.
So while language X now needs a second quad-core box, and maxes both of those out at less than 2000 requests/sec, language Y is running fine on a single box, and individual requests are still served much quicker from start to finish
Multiply that scenario by a million redundant servers, plus electricity, ac, space, management, etc, to begin to understand what inefficient languages really cost us all. A billion here, a billion there, and soon you're talking real money!
The servers that it did take over are now directly threatened (as are the database servers that they communicate with via java) by map-reduce and nosql. Much more scalable, no dependence on Oracle for anything, runs fine on commodity hardware, much easier to synchronize as well as build in transaction isolation and rollback.
10 years. That's an eternity in internet time, but not in human time, and the continued growth of data stores and rising energy costs make it not only possible, but inevitable.
Just enum RED_LIGHT=0, YELLOW_LIGHT, GREEN_LIGHT then either jump to the offset at LIGHT_FUNCS+light*PTR_SIZE, or if you've created an array of function pointers, set lights[NORTH_SOUTH] = light_funcs[light]; Your code becomes more generic, even though the code for handling a red light may be completely different than the code for a green light, which may, for example, refuse to set itself to green if lights[EAST_WEST] is still green, setting the function lights[NORTH_SOUTH] pointing back to light_funcs[RED_LIGHT], and return, rather than a whole bunch of trys, cases, ifs, and exception handlers.
The best part is that you can now tie this (by using the volatile keyword) into a real-time external process that changes one byte of ram. Set up a thread to check that address every second and you've got your light controller for that street corner.
Need to expand it to 10,000 street corners? Not a problem - your total memory requirements only grew by 2*sizeof(ptr), plus 2 byte for light state (000=both_blinking_red, 001=both_red, 010=nsgreen, 011=ewgreen, 100=nsyellow, 101=ewyellow) and seconds_elapsed (a 13-bit integer - good for more than 2 hours); Even on 64-bit systems, the whole 10,000 light controller (data and code) would fit into well under 200k. On a 16-bit system it could probably be shoe-horned into 64k (in this case it's the pointers that eat up the space on 64-bit systems - 20,000 pointers only take up 40k on 16 bits).
There's no way you'd ever get that to run in 64k under Java - just the run-time takes a LOT more than that.
You use pointer arithmetic to design more efficient algorithms, duh!
In other words, come in one afternoon or evening a week, or on a weekend, and sit in on the interviews, then give your opinion on the pros and cons of the candidate.
Certainly a lot better than anything that a recruiting agency will do, and cheaper in the long run.
All that is well and good, but it ignores my key point - the vast majority of IT failures have nothing to do with people's technical skills, but management's failure to communicate. Technical skills can be acquired (and when you're developing new technology, obviously it's the only way to go, since there is no prior art, etc.) - communications skills, obviously not so easily.
The use of extensive testing is an easy way to cover up for the lack of a proper way to assess the more important aspect - is the person a good communicator? Not in the "marketing/powerpoint/bs" fashion, but can they take a concept and teach it to someone else on the team?
Stick them in front of a whiteboard and have them give a talk about something. Did you understand it? If so, they've demonstrated 4 things - that they know it, that they know it well enough to explain it to others, and that others can understand their style of communicating, and that they also know how to listen (more on that in a sec).
15 minutes to a half-hour should be all that's needed. If they wash out on communications skills, then it doesn't matter how hot-shot prima donna they are with code. If they're good communicators, they got that way by listening to others, and adapting their "pitch" to the abilities of their audience.
It's a simple test, with a simple pass/fail standard - did you understand what they were talking about? If they bored the crap out of you, they're a poor communicator. If they kept having to pause for 15 seconds to 1 minute to "fill the pipeline", they're not really on top of the subject matter, so you've also eliminated the "BS-ers".
You also get to see if they're really enthusiastic about what they do, or if it's just a job, so you cover the "desperate for a job" motivation as well - someone who's enthusiastic will easily be able to go beyond the 15-30 minutes. It also lets you see if anyone else in the room is not going to be a good fit, personality-wise, during any Q and A. Do they get into a "pissing match?" If so, who started it, and how did the other person handle it? (You might want to have a "plant" for doing exactly that).
Of course, this is just too simple and obvious, just like using two screens is a simple and obvious way to improve productivity, from secretaries to coders and everyone else, but most companies won't do it.
Fear. They'd rather trust in some mythical scores so that if it doesn't work out they can CYA by saying "the checkboxes looked good." Do we pick our other relationships like that? I hope not - and work is just as much a relationship as any other.
And before we get into *that* argument again ... Java is no more compiled than converting a word doc to a pdf is "compiling" it. You cannot execute the resulting class files directly - they need to be interpreted by the run-time (originally, they were supposed to be interpreted by a special "Java chip" - "write once, run anywhere" was the exact opposite of the original design goals).
If Sun had had any brains, they would have fixed the slowness of Java by including the ability to compile down to native code. Then they could have arguably had the best of both worlds.
But what do you expect from a project that changed its goals so many times, even in the early years?
Java, because you can't use pointer arithmetic, is going to be slower than the same code in c using pointer arithmetic, because a non-pointer solution is always going to be slower, in any language, even c.
The lack of pointers was the only way that Java could be implemented. Another reason was to keep both the class verifier the garbage collector simple. You can't "prove" code that can point to something different during the actual run. Both these restrictions introduce behind-the-scenes overhead, as well as restricting what you, the programmer, can write.
The lack of first-class functions is also another area where you are restricted in what you can code. You can't just have, say, a nice tight loop that executes a function, and calls address+mode*size_of_pointer_to_function - you need to write a switch or if/else. For things like modal parsers, this makes a difference. No one-line while() or for() for YOU! Your code, which fits nicely into the cpu cache, L1 cache, probably won't in Java, so the performance hit will be huge.
Java will eventually lose ground there as well for several reasons:
#2 is currently the big issue. Once a Java project passes a certain complexity, any "it's simpler in Java" advantage is lost, and the Java language and development environment become a boat anchor.
Try such basic stuff as pointer arithmetic.
In c, it means that you get in the habit of typing free() right after typing malloc(), then asking yourself, where does the free() really belong? Who is going to "own" this memory. If it doesn't fit naturally within that block, you need to make sure that it's taken care of somewhere else. Move the free() there, and paste in a comment as to who frees it.
In c++, it means making sure that every object owns its own resources, or you enforce a contract with any object it serves as a "factory" to, that the recipient will free it, but not both.
It is possible to write leak-resistant (even leak-free) code. It just takes some attention to detail. But at that point, you have a detrministic program, not one whose performance is dependent on when/if a garbage collector decides to do some cleanup - and you can also do away with the whole {smart|weak}_ptr garbage.
Php became the #1 web server language in 2002 - and that hasn't changed since, and isn't likely to. Most web sites don't use jsp/struts/spring/jsf
We call it a LAMP (or WAMP) stack for a reason.
Maybe we can get them to sue facebook (poke, etc.) and kill 2 birds with one stone? A win-win.
And TV stations for running newscasts and current events shows. And newspapers - they're dying anyway ...
Dream on if yo believe that the JIT is competitive. Even if it were able to pre-compile everything to native methods, you still lack some of the essential programming models that people have been using for decades to make things go faster.
Basically, what happened is that the judge decided that, since he was able to toss the patents w/o having to rule on the validity of the USPTOs actions, he was required to ignore that part of the case, Kind of sucks, but once it gets through the appeals process, it will be another fork in the "stupid patents" model.
We already had "slow-scan tv recorders" back in 1972 in Popular Science magazine. You could record a single image on an audio tape cassette in about 20 seconds. And as you can see from the article, it's been around since 1960
Except that Android doesn't run Java classes - it runs dalvik classes. It's like you taking a .doc file and converting it to pdf so that people don't need the Evil Word.
Java's dying anyway. It's a lot slower than dalvik, and Java simply hasn't lived up to its "write once run anywhere" claims. Just like it hasn't lived up to earlier promises to "reinvent the desktop", or before that, to "change the way we use the Internet with applets - remember them - to add interactivity.
What are they going to do when dalvik is extended to run on regular servers, and all those Java support contracts dry up? Just like is happening right now in the mobile space with the multi-fragmented JavaME?. Pretty bad when your core market tells you that the competition already raided your fridge, ate your breakfast and lunch, and took a dump on your supper.
Linkedin is no better.
The process is broken, simple as that.
Your resume says NOTHING about who you are, and what you can do. It makes no difference between 20 years experience, and 1 year 20 times. And everyone lies on there resumes.
Keyword matching is the worst - and it's going to cost you candidates.
My resume had zero experience writing multithreaded servers in c, but the place I eventually worked at, their lead was leaving, and they had tried a half-dozen others before they decided to "scrape the bottom of the barrel" by going to an "older" worker - which by their definition was anyone over 30. The code was terrible, the database design sucked, there was no documentation, and it was obvious why the lead had left for greener pastures - it was "fish or cut bait" time. He had milked this job as far as he could.
So, get familiar with the code, study the posix threads docs online, and start fixing the problems. End result was 3 inter-related specialized linux/bsd-hosted servers (depending on -DBSD for make) that can handle a thousand requests a second (including db lookups on the same low-end hardware), never kills off a thread to "reclaim memory" (zero memory leaks, even after running for months at a time), and it does the job.
Only one problem - the code was now stable enough, and clean enough, that I was no longer needed, and the extra delays meant a round of cost-cutting.
The job hunting process since then has convinced me, more than anything else, that most people doing "recruiting" don't have a clue, and that employers aren't willing to take the logical step - hire a programmer on a contract basis to help them weed out candidates.
It's also why I absolutely refuse to hand out a resume. I am *not* my resume, and my resume is not me. If you have a problem, either I can fix it, or I'll tell you that I can't. The main concern really isn't that anyway (studies show that the leading cause of project failure is bad communications, not lack of technical skills).
Adding "On the Internet" or "In a web browser" is not innovation.
The 507 patent ()2001) falls to prior art - RoboBoard, bbs that downloaded graphic primitives and let you navigate through a virtual world (never mind just audio-visual data). Also the Space Quest and Kings Quest games, etc.
The 602 and 314 patents "Attention Manager for Occupying the Peripheral Attention of a Person in the Vicinity of a Display Device." is preceded by, among other things, those annoying tickertape displays that have been around for decades, wall clocks for anyone sitting in front of a computer at 4:55 PM, etc.
The 682 patent "Alerting Users to Items of Current Interest." (2004) is anticipated by the flag on your mailbox that lets you know you have mail, your doorbell, TV Guide magazine, the front page of any newspaper sitting at the news stand, etc. And of course, "You have mail".
Maybe this will the the one that finally puts the end to stupid software patents.
I would hope so. Who would be stupid enough to do that for free? Oh wait, he went and admitted he was doing it - we have a WINNER*!!!
(* only for values of "WINNER" meaning "LOSER!". Avoid listening to him while driving, it may cause drowsiness or road rage. Avoid taking on a full stomach, you may toss your lunch. Avoid voting for in the next election - your cable bill will be highter.)
Motorola, Samsung, LG, HTC, Apple, even Microsoft would disagree with you. And then there's everyone who uses one - take away their Blackberries and watch several governments falter.
You're the one that doesn't get it. Software execution speed matters to everyone. Look at the new smartphone commercials emphasizing how much faster Android is than an iPhone. Additionally, energy costs matter. Java loses there, same as Windows does to linux or bsd.
Also, data access is only one bottleneck, and you can always work around it if you have any smarts and aren't locked into a crappy platform. Any time you can eliminate one bottleneck, you can do more work. Additionally, map-reduce renders relational databases obsolete, as well as removing the bottleneck.
Get real, stop being childish. Everyone is now looking for alternatives to Java because of this lawsuit, and realizing they're locked into a slow bloated platform.
"I've never put it up for sale, and while I *have* had a few unsolicited offers in the past, and out of politeness I *will* look at them, there's been nothing so far to make me change my mind."
You establish:
As in all negotiations, the person who speaks first loses. Remember that next time you find yourself on a used car lot.
No, you're right - it's not the keyboard, it's the PEBKAC- the person who decides to run an OS that can't handle something as simple as a keyboard being unplugged :-)