One problem people are reporting is that the overlaid ad makes it very difficult to see where to stop fast forwarding.
Also this happen on a rewind too if you read the Tivo forums. And due to a bug its displaying during the programs and not during the adds if you pause live.
This is actually a serious question as it relates to algorithmic complexity. One question is whether the savants are finding more efficient solutions to classes of problems than those currently known to computer scientists. This would be a particularly important result for things like the NP-complete problems. But in the testing that occurred during my college years, it was found that the time complexity of the solution was exponential in the problem size and therefore the savants were not solving the problem using an unconcious algorithm that was faster than exponential time.
The Java Advanced Imaging API which is part of the class library ships with a Java and some native implementations. This is done purely for performance reasons because the pure Java version does not perform well.
In fairness to Java, I think this is because that library is not written well. My company made its own imaging routines that cover part of its functionailty and they are substantially faster.
One of the points in the article is that the JIT compilers did not do well with Swing code because it did not have hot spots. Any type of after the fact compile is not going to perform well if it can't identify the parts of the code that need to be compiled.
Microsoft is not a healthy software company. Their desire to outsource is an indication of the larger internal problem.
If your company produces art, you cater to your artists or you fail. Microsoft has an enourmous amount of cash which has given it some economic inertia, but it is not innovating and that is killing it. What is their response to Linux, a further delayed somewhat vague OS idea? What is their response to Firefox, a 3 year old browser version?
The companies that outsource the things that they shouldn't are sowing the seeds of their future failure. Oracle's outsourcing is creating their own future competitor.
I am not "pro" outsource. I am a programmer and I obviously want to stay employed. But these doom and gloom stories are plain illogical. In the same way that we have manufacturing jobs here even though we also export many manufacturing jobs, there will always be programming jobs in this country even though we also export a lot of programming jobs. Until some technological advance makes programming unnecessary and then we will be the makers of the programs that make the programs we use.
No doubt the industry is changing but I do not think it is valid to lump every different kind of programmer or job into one category and say that it is being outsourced.
The most obvious outsourcing occurs in companies that have IT departments but are not in themselves a software development company. For instance, a bank and it's IT department. These IT departments are a commodity for the non-tech company and they are looking to satisfy that commodity at the cheapest possible price. And the types of jobs being exported are very basic types of programming that could be compared to the simple manufacturing jobs that are also exported.
This is a very different situation from a software company where the programmers are not considered a commodity. This might not be true for the very large software companies but that is also an indication of their dysfunction.
The jobs are flowing to India purely because of the low cost. As India develops a large middleclass due to this influx of money, wages will rise and the value proposition will worsen for India. That's when the jobs will start flowing to China. India is not necessarily in the best position, long term.
Part of the confusion is that the name Generics implies that it is something it is not, to people with more experience than just java.
In a nutshell, java generics give you type-safe containers. Properly used, this will shift runtime ClassCastExceptions to compile time. You will not need to explicitly cast items coming out of the collection. That's all it does.
The real tragedy with generics is what it could have been. Just do a google search; a lot of people are unhappy about the consequences of erasure. And Sun's justification for erasure is not satisfying.
Java poor design choices
on
Java 1.5 vs C#
·
· Score: 2, Insightful
My biggest beef with java right now (well Sun, really) is that they are make design decisions in the name of backward compatibility that are leading to poor design choices. Backwards compatibility is an important consideration, but it should not be used as an excuse to make poor design decisions. I use a variety of java programs day to day that only work with certain VM versions due to bugs, features, etc. It seems silly to give this one aspect such heavy consideration as if the current java versions are perfectly backward compatible today when they clearly are not.
The new generics feature is clearly patterned after C++ templates, but in the name of backwards compatibility Sun chose to implement generics using erasure. This means that a generic type loses all of its type information leading to a alot of issues including broken support for arrays. Using erasure keeps much of the potentially confusing syntax of C++ templates and virtually none of the power.
I suppose I would be less upset if the feature had a different name. Maybe something like AutoCasting (like the name AutoBoxing). "Generics" implies things that the feature does not even try to deliver. Adding true generic programming constructs to java would have been a huge leap forward for the language. Instead we are left with a toy feature that allows you to build type safe containers, nothing more. Very disappointing.
It's not just about fixing the upcoming version. If any existing users are affected by the security problem, they need to be patched and on a faster timescale then whenever the new release is ready.
I don't think it is fair to apply typical beta, pre-release, or 1.0 reasoning to Firefox. It has undergone a successful marketing campaign and is clearly advocating users to switch "right now" on its main web page. So it's a bit of a cop out to then say ignore this issue its not ready for prime-time yet.
In this case it may seem like much ado about nothing but what about next time? No process is so perfect that it can't be improved and these sorts of self reflective posts are a good thing.
The whole point of generic programming is that you don't want to know the SomeInterface ahead of time. You have two independent libraries. An class in one library is not going to implement the required interface from the other library. Your only recourse is to wrap the class with a new class that implements the interface.
From the standpoint of making the function generic, the T extends SomeInterface method is no better than simply making the function take an argument of type SomeInterface. The only possible advantage I see is for templated return values and again it's just to avoid explicit type casts. Note, this isn't even preventing a class of problems because misuse of the explicit type-cast still leads to a compile time error.
Of course another unfortunate thing is that the syntax is inconsistent in that extends is for inheritance, and implements is for interfaces.
Generics also let the compiler enforce valid typecasting.
That's not exactly true. Generics provide automatic typecasting and that's really it. The underlying rules are unchanged.
One very common construct in generic programming as implemented in other languages is defining a template function that deduces its type at compile time.
For example:
public <T> void foo(T o) { o.somemethod(); }
If this worked like other generic languages, you would be able to make this call passing any type of parameter that included somemethod(). And this would be enfored at compile time.
This does not work in Java because generics are implemented using erasure. So in this "any" type example, only methods of Object are callable.
This is unfortunate because it make generics only useful for the casting problem with containers.
I was actually looking forward to templates in Java but was disappointed once I saw the implementation of generics.
Every cast operation in Java is expensive because the VM invokes security code to verify that the cast is legal. Java generics don't allow you to avoid the implicit cast so you still get the performance hit. Generics only make the code look cleaner.
Template meta-programming is also a very important part of the modern C++ libraries and is also something that generics cannot do.
I have experienced that too. One thing that is odd is that I have no problem chatting with a person ingame, but if someone walks by and talks to me ouside the game its difficult for me to figure out what they even said.
I also experience this while programming and also on long drives.
Re:Nope, wrong, invalid.. nothing to see here.
on
The End of Encryption?
·
· Score: 4, Interesting
Also, if a P=NP proof was found it would not necessarily gives us a procedure for generating the P algorithm that solves the NP complete problem. This would be an unfortunate situation.
The press rightly continues to use the word 'piracy' for illicit copying and distribution of original materials.
You also mention the would theft also. One of the judges in the Grokster case had this to say to one of the lawyers against Grokster.
"Let me say what your problem is. You can use these harsh terms, but you are dealing with something new. And the question is, Does the statutory monopoly that Congress has given you reach out to that somthing new, and that's a very debatable question. You don't solve it by calling it theft. You have to show why this court should extend a statutory monopoly to cover the new thing. That's your problem. So address that, if you would, rather than use abusive language."
This was more or less the argument behind Case tools in the 80s. Only it didn't work because the benefits didn't outweigh the tradeoffs.
People overstate the protection afforded by languages like Java and then ignore what you give up for that protection. And no I'm not talking about performance.
For instance, none of the standard synchronized collection classes are thread safe. They only give the illusion of safety.
People like to point to the lack of pointers as a positive but then dismiss the lack of a deterministic destructor as a minor problem. Meanwhile serious resource leaks are common in Java programs because people fail to adequately test all their exception paths to make sure things are freed correctly in all cases. In C++, for instance, this problem is handled using a coding practice where the constructor allocates and the destructor deallocates. In Java the burden is on the programmer to get this right, in C++ the programming practice puts the burden on the compiler.
I don't really think a language can be the "safe" tool you are describing. The safety comes from how you use the language; your practices and habits. In the same way that a calculator will give you the result you asked for but will not tell you that you applied the wrong formula.
Slashdot Mirror
Or Tapestry.
When flash-based popups started cropping up, I uninstalled flash and I have not missed it at all.
One problem people are reporting is that the overlaid ad makes it very difficult to see where to stop fast forwarding.
Also this happen on a rewind too if you read the Tivo forums. And due to a bug its displaying during the programs and not during the adds if you pause live.
This is actually a serious question as it relates to algorithmic complexity. One question is whether the savants are finding more efficient solutions to classes of problems than those currently known to computer scientists. This would be a particularly important result for things like the NP-complete problems. But in the testing that occurred during my college years, it was found that the time complexity of the solution was exponential in the problem size and therefore the savants were not solving the problem using an unconcious algorithm that was faster than exponential time.
C looks just as bad if you remove all whitespace and put multiple statements on a line.
So by that logic you are also against Linux since there were free Unix implementations already available?
The Java Advanced Imaging API which is part of the class library ships with a Java and some native implementations. This is done purely for performance reasons because the pure Java version does not perform well.
In fairness to Java, I think this is because that library is not written well. My company made its own imaging routines that cover part of its functionailty and they are substantially faster.
One of the points in the article is that the JIT compilers did not do well with Swing code because it did not have hot spots. Any type of after the fact compile is not going to perform well if it can't identify the parts of the code that need to be compiled.
Microsoft is not a healthy software company. Their desire to outsource is an indication of the larger internal problem.
If your company produces art, you cater to your artists or you fail. Microsoft has an enourmous amount of cash which has given it some economic inertia, but it is not innovating and that is killing it. What is their response to Linux, a further delayed somewhat vague OS idea? What is their response to Firefox, a 3 year old browser version?
The companies that outsource the things that they shouldn't are sowing the seeds of their future failure. Oracle's outsourcing is creating their own future competitor.
I am not "pro" outsource. I am a programmer and I obviously want to stay employed. But these doom and gloom stories are plain illogical. In the same way that we have manufacturing jobs here even though we also export many manufacturing jobs, there will always be programming jobs in this country even though we also export a lot of programming jobs. Until some technological advance makes programming unnecessary and then we will be the makers of the programs that make the programs we use.
No doubt the industry is changing but I do not think it is valid to lump every different kind of programmer or job into one category and say that it is being outsourced.
The most obvious outsourcing occurs in companies that have IT departments but are not in themselves a software development company. For instance, a bank and it's IT department. These IT departments are a commodity for the non-tech company and they are looking to satisfy that commodity at the cheapest possible price. And the types of jobs being exported are very basic types of programming that could be compared to the simple manufacturing jobs that are also exported.
This is a very different situation from a software company where the programmers are not considered a commodity. This might not be true for the very large software companies but that is also an indication of their dysfunction.
The jobs are flowing to India purely because of the low cost. As India develops a large middleclass due to this influx of money, wages will rise and the value proposition will worsen for India. That's when the jobs will start flowing to China. India is not necessarily in the best position, long term.
A trebuchet!
Or cherries to pears?
You aren't alone. See this thread.
Part of the confusion is that the name Generics implies that it is something it is not, to people with more experience than just java.
In a nutshell, java generics give you type-safe containers. Properly used, this will shift runtime ClassCastExceptions to compile time. You will not need to explicitly cast items coming out of the collection. That's all it does.
The real tragedy with generics is what it could have been. Just do a google search; a lot of people are unhappy about the consequences of erasure. And Sun's justification for erasure is not satisfying.
My biggest beef with java right now (well Sun, really) is that they are make design decisions in the name of backward compatibility that are leading to poor design choices. Backwards compatibility is an important consideration, but it should not be used as an excuse to make poor design decisions. I use a variety of java programs day to day that only work with certain VM versions due to bugs, features, etc. It seems silly to give this one aspect such heavy consideration as if the current java versions are perfectly backward compatible today when they clearly are not.
The new generics feature is clearly patterned after C++ templates, but in the name of backwards compatibility Sun chose to implement generics using erasure. This means that a generic type loses all of its type information leading to a alot of issues including broken support for arrays. Using erasure keeps much of the potentially confusing syntax of C++ templates and virtually none of the power.
I suppose I would be less upset if the feature had a different name. Maybe something like AutoCasting (like the name AutoBoxing). "Generics" implies things that the feature does not even try to deliver. Adding true generic programming constructs to java would have been a huge leap forward for the language. Instead we are left with a toy feature that allows you to build type safe containers, nothing more. Very disappointing.
It's not just about fixing the upcoming version. If any existing users are affected by the security problem, they need to be patched and on a faster timescale then whenever the new release is ready.
I don't think it is fair to apply typical beta, pre-release, or 1.0 reasoning to Firefox. It has undergone a successful marketing campaign and is clearly advocating users to switch "right now" on its main web page. So it's a bit of a cop out to then say ignore this issue its not ready for prime-time yet.
In this case it may seem like much ado about nothing but what about next time? No process is so perfect that it can't be improved and these sorts of self reflective posts are a good thing.
The whole point of generic programming is that you don't want to know the SomeInterface ahead of time. You have two independent libraries. An class in one library is not going to implement the required interface from the other library. Your only recourse is to wrap the class with a new class that implements the interface.
From the standpoint of making the function generic, the T extends SomeInterface method is no better than simply making the function take an argument of type SomeInterface. The only possible advantage I see is for templated return values and again it's just to avoid explicit type casts. Note, this isn't even preventing a class of problems because misuse of the explicit type-cast still leads to a compile time error.
Of course another unfortunate thing is that the syntax is inconsistent in that extends is for inheritance, and implements is for interfaces.
Generics also let the compiler enforce valid typecasting.
That's not exactly true. Generics provide automatic typecasting and that's really it. The underlying rules are unchanged.
One very common construct in generic programming as implemented in other languages is defining a template function that deduces its type at compile time.
For example:
If this worked like other generic languages, you would be able to make this call passing any type of parameter that included somemethod(). And this would be enfored at compile time.
This does not work in Java because generics are implemented using erasure. So in this "any" type example, only methods of Object are callable.
This is unfortunate because it make generics only useful for the casting problem with containers.
I was actually looking forward to templates in Java but was disappointed once I saw the implementation of generics.
Every cast operation in Java is expensive because the VM invokes security code to verify that the cast is legal. Java generics don't allow you to avoid the implicit cast so you still get the performance hit. Generics only make the code look cleaner.
Template meta-programming is also a very important part of the modern C++ libraries and is also something that generics cannot do.
Pascal isn't that much different than C. It's still a low-level language. I think a better suggestion would be Lisp or Haskell.
I'm having a hard time remembering the last time I used a floppy. Between a network and a USB dongle...
And when something is too large I burn it to a CDROM or DVDROM.
I have experienced that too. One thing that is odd is that I have no problem chatting with a person ingame, but if someone walks by and talks to me ouside the game its difficult for me to figure out what they even said.
I also experience this while programming and also on long drives.
Also, if a P=NP proof was found it would not necessarily gives us a procedure for generating the P algorithm that solves the NP complete problem. This would be an unfortunate situation.
Do a google search on: java security hole.
Just because you don't hear about the vulnerabilities doesn't mean they don't exist.
The press rightly continues to use the word 'piracy' for illicit copying and distribution of original materials.
You also mention the would theft also. One of the judges in the Grokster case had this to say to one of the lawyers against Grokster.
This was more or less the argument behind Case tools in the 80s. Only it didn't work because the benefits didn't outweigh the tradeoffs.
People overstate the protection afforded by languages like Java and then ignore what you give up for that protection. And no I'm not talking about performance.
For instance, none of the standard synchronized collection classes are thread safe. They only give the illusion of safety.
People like to point to the lack of pointers as a positive but then dismiss the lack of a deterministic destructor as a minor problem. Meanwhile serious resource leaks are common in Java programs because people fail to adequately test all their exception paths to make sure things are freed correctly in all cases. In C++, for instance, this problem is handled using a coding practice where the constructor allocates and the destructor deallocates. In Java the burden is on the programmer to get this right, in C++ the programming practice puts the burden on the compiler.
I don't really think a language can be the "safe" tool you are describing. The safety comes from how you use the language; your practices and habits. In the same way that a calculator will give you the result you asked for but will not tell you that you applied the wrong formula.