Did you watch the program? I didn't, but am curious how it was presented.
No, I didn't have the opportunity. I'm hoping that I'll be able to find it online. From what I understand, it was pretty fair. Even the left-wing dailykos.com's summary seems to indicate that it was balanced, which is somewhat surprising, given their venomous attitude toward Republicans and their apparent love for hyping the "right-wing conspiracy theory du jour".
Not sure I agree that atrocities were committed to Sinclair. They really went out on a limb to broadcast this news program, and it seemed that the "Under Fire" program was the initial concern, the final program just a last minute CYA. It is unusual for them to produce a news program, and really opened the door for the critism they received. And it was a no win situation. If they presented either candidate in a negative light, that candidate's supporters would cry foul. The fact that they have more history as a partisan supporter than as news organization caused the outrage and the allegations.
Oh, I wasn't trying to say that, literally, atrocities were committed against Sinclair. It's not like they were publicly flogged or anything like that.
I do think that they were prematurely attacked and the media's coverage of it was misleading. Sinclair was fairly quick to respond, saying that the program's content was still being decided and any characterization of the program was premature. I knew that the program would probably be unpolished, given that they hadn't finished it until the last minute. At the very most, I could understand it if a group of people publicly threatened to boycott them if the program was too biased. Instead, people immediately took action against Sinclair as soon as the story broke, and Sinclair received, and is still receiving, much more than just criticism. Call me crazy, but I believe that someone has to do something wrong before they're punished for it.
I'm not sure if Sinclair actually planned to air an hour-long anti-Kerry smear program. That's entirely possible. But I think the media's coverage and public outcry was enough to dissuade them from that alleged plan. Instead, things got out of hand. Certain people falsely claimed that they knew that Sinclair was going to broadcast "Stolen Honor", and others claimed that it was officially announced. People protested, Sinclair was boycotted, and their execs were subjected to personal attacks. These aren't "atrocities", but they certainly show that people can easily be influenced to do some awful things.
"Those who can make you believe absurdities can make you commit atrocities." --Voltaire
That's a great quote that is highly relevant here. I think the folks that are outraged by the media's reports on this issue need to step back and consider the evidence that supported the allegations, because it was very weak.
The best evidence of their alleged nefarious intentions were some TV listings (possibly accidental mistakes), a fired employee that said they were discussing airing the documentary (but weren't sure what they were going to air), and the fact that they were considered conservative. For that, their advertisers were harrassed, their investors were contacted with requests to sell their stock, and the execs "endured personal attacks of the vilest nature". It was obvious to me that the media's reports caused things to get out of hand, and the assault upon the demonized Sinclair was incredibly premature.
One of the issues I think is that if you incorperate a certain level of sophistication into your code then people who can not program to that level think it is much too complex.
Take perl for example (mostly cuase you said ick;-]). Perl is highly idomatic with "More Than One Right Way" to do things. Simple perl code is simple and easy to understand; however, the uninitiated will find it next to impossible to understand how the "magic" of some perl modules works. Modules that use things like glob refs, tied data structures, export, and eval to achieve great new additions to the language in ways that seem impossible.
Who is to blame for this? My instinct tells me that it is the novice that should learn the constructs used in the master's code, but I realize that there is a limit. If someone is using a highly advanced language feature to eliminate a few lines of code, then he is probably going overboard. However, if the code is more robust when the feature is used, then the advanced feature is probably warranted. After all, correctness is the #1 priority. Unfortunately, at first glance, the unfamiliar novice will probably not realize the benefits of the advanced feature and will assume it is unnecessary until it has been explained to him/her. This is especially problematic when the novice does not wish to learn the advanced features of a language.
I also think people make a big scene to managers that the previous developer's code was bad simply to make themselves look good. The manager who usually doesn't code says to themselves "Well he must be a great coder if he thinks the previous developer didn't know what he/she was doing."
Another developer cliché is to complain about documentation. Doesn't matter if you write a war and peace size document to explian everything, the next developer is totally not going to read it. The next developer if he/she doesn't understand it simply says "This code is crap". This buys more time to become competent at programming changes and makes them look like a top coder to the credulous manager.
Where in the hell did you learn to write, anyway? How on earth do you expect someone to understand that incomprehensible mess? Your writing style is absolutely atrocious. Are you a native English speaker? I've met two-year-olds with better communication skills. The simple fact that you started a sentence with "Doesn't matter" instead of "It doesn't matter" means that your entire comment is garbage and should be rewritten. Oh, and it's explain, for God's sake. I won't even bother to comment on the lack of commas.
Super programmers often hurt a team more than they help.
Alot of brilliant engineers and programmers are brilliant for a good reason: their brains are wired to intuitively grasp what mediocre programmers need to explicitly think about.
There's a downside to that as well; namely that those individuals do not have the best communications and personal skills.
That doesn't follow. One can find complex things intuitive and have good communication skills. Many people can explain their "intuitive" ideas. Those are the _real_ super programmers.
Sometimes I want to know, as I'm writing my code, exactly what low-level operations will occur when that code gets run. My code, not the libraries I'm calling. Java doesn't even let me do that.
It's a pretty rare "sometimes", though -- I don't do so much low-level work these days. As far as the why of the matter, I think someone wrote a paper about leaky abstractions that explains it pretty well.
It's not a straw man because the original post said it differently. The key word present now that was not originally present: sometimes. You even admit that it's very rare that one would want to know what low-level operations are involved when executing code, and that's very damaging to your original claim that certain people need to avoid back boxes altogether. In actuality, such people would skip Java, Python, and C and opt for assembly code.
The thing is, one could take that "my code" comment to the extreme and say that it is no longer "my code" when it is run through a compiler that might optimize it, or, to take it even further, it is no longer "my code" when it is not written in zeros and ones. You're dealing with abstraction wherever you turn, so let's not pretend that intepreters are so different from compilers.
That "leaky abstractions" paper you're referring to was very weak. It was written by Joel (of "Joel on software") and it was just about the worst material of his that I'd ever read. He even went so far as to claim that the performance of an abstraction can make it leaky, which rendered the definition of "leaky abstraction" pointless, because the implementation of an abstraction would have to run in no time at all to avoid being leaky. No implementations run in no time at all, so every abstraction is leaky, so the definition of "leaky" is worthless because it adds no new meaning to the term abstraction. It was a paper that appeals to programmers who simply don't like abstractions and want to stick to lower-level languages and in-house libraries.
Errors indicate a serious virtual machine malfunction.
What you are describing is actually VirtualMachineError, not Error. The Error class is merely for exceptions that you probably won't want to catch. OutOfMemoryError is derived from VirtalMachineError, but that's probably not a good idea, considering that the other classes derived from that class (InternalError, UnknownError, StackOverflowError) are far more serious.
While OutOfMemoryErrors are surely more common while allocating large amounts of memory, they can also occur during the allocation of small objects in which case your options to handle them may be seriously reduced.
While that seems to be the case at first glance, once you take unwinding of the stack and the execution of finally blocks (as well as the unlikeliness that the error will even be thrown when allocating a small object) into consideration, it becomes apparent that it is extremey unlikely that handling an OutOfMemoryError will prove to be difficult unless that handling uses a lot of memory, which would be foolish, given the type of error that occurred.
IHMO, the reason that handling an OutOfMemoryError may be difficult has little to do with the need to allocate memory within the handling code. The simple fact is that most Java code was not written with OutOfMemoryErrors in mind and assumes that the application will terminate when one occurs. This assumption is hardly ever documented. Unfortunately, a lot of server-side code has to remain running even when such errors occur. Unless the code specifically documents the fact that OutOfMemoryErrors are handled gracefully, then you have to assume that the internal state of the objects used could be corrupted.
As an example, consider a method that must update two Hashtables inside of an object, and it is required that both succeed (updating only one would violate the contract provided by the object). In most Java code, if the first update succeeds, and the second fails due to an allocation failing (possible but unlikely), the object's state will be corrupted. After an OutOfMemoryError, figuring out what state your application is in can be hard, if not impossible, unless every piece of the executing code does not assume that OutOfMemoryErrors are grounds for termination.
It could be that I'm taking out of memory conditions too seriously. I did come from a C++ background, and C++ programmers tend to write their code with low memory conditions in mind. Java programmers, on the other hand, seem to mostly ignore memory allocation failures.
The demos are really cool. But the biggest issue, which I think is apparent in the demos also, is that you get these frame rate drops. The best I can tell from playing around with Java3D, this happens because the API is allocating a bunch of objects during rendering. The garbage collector has to come by and get rid of them and it takes long enough to release the unused objects that it interferes with the rendering thread. This turns out to be down right distracting in animation.
What? I've used Java3D, and it seems to me that they went through great pains to ensure that nothing is allocated unless you ask it to be allocated. You're right, the GC can interfere with the rendering thread, but I've never had an issue with the Java3D library causing the GC to kick in. In fact, the Java3D API can look a little awkward when you're used to APIs that are not so sensitive about allocation. They usually design their APIs so you can reuse previously allocated objects. That way, you don't have to release them to the GC, and your performance is more predictable.
For an example of this, examine the GeometryArray class. First, note that it is highly mutable. Everything about the object can be modified, so you never have to create another instance if you already have a spare one lying around. Also, take a look at how all of the setXXX() functions are overloaded so you never have to allocate an object to call the setter. While the API could have just provided one set() method and required you to create an object of the correct type to call it, they decided to instead overload it for any reasonable type that could be used to represent that property.
Are you sure that it's Java3D that's allocating the objects and not the code you wrote?
WebSphere Portal 5 bundled in some web based word/excel replacements. I think the idea was "use our portal, and use us to view (and edit) business content. You don't need office!" The reality was less than inspiring. I'd put it on par with the large number of RTF/HTML editors out there - clunky. Not sure why they did not put their weight behind OpenOffice, because it is head and shoulders above what they included with the Portal.
I think you've got it. Most everyone else is thinking that it's a Java-based solution, but I've seen the software bundled with Portal as well, and I think that this article might be about those editors. You're right, they are a tad clunky, but they don't require a JVM and, according to IBM, they work on many different browsers. It was the furthest I'd ever seen Javascript pushed, and I was surprised that they had the guts to go that far with the language.
[In reply to my statement "No software design should be solely based on English expressions."]
If you believe that, you're a moron.
Forget about 'english'. If you can't express a design in plain natural, human, language, the design is fit for nothing other than the garbage.
Instead of criticising, why don't you come up with an alternative, then maybe you'd be worth wasting time on.
Ah, I knew someone would misinterpret what I said. I was trying to say that no software design should be solely derived from some plain-language description of a problem that has no basis in programming concepts. That is what is commonly done in the "OO beginner" software (e.g. "A car is a vehicle, so we will make the car class derive from the vehicle class"). I was not trying to say that it is best if software designs are impossible to express in plain language. That would be silly.
I advocate designing your objects for flexibility and maintenance. I don't like justifications of object relations that are little more than "Well, of course Foo inherits from Bar because a Foo is a Bar. Don't you get it?" Instead of doing that, I like to take a similar approach to the one Design Patterns use. They create objects and object relations based on coupling issues and what is likely to change, not because they get a warm fuzzy feeling when they say "is a" between the class names.
In college, many moons ago, I was taught a simple rule for determining whether to use composition or inheritance:
If it's an 'is a' relationship, use inheritance.
If it's an 'has a' relationsip, use composition.
If it's neither sort of relationship, keep the classes separate.
This is the "Dummy's Guide To OO" explanation of inheritance and composition. It should only be used to explain these concepts to someone unfamiliar with the terminology. As an AC pointed out, these are definitions, not guidelines for design. No software design should be solely based on English expressions.
Other virus's do all sorts of nasty things, but they all seem to stop short of REALLY bad things. Search for files they can delete, look for a network drive and have their way, find interesting files and mail to random people, rename this or that to render the machine useless.....
A useless machine is... well, useless. Unless the author gets off on chaos, it's pointless to disable the machine. A zombie that you can remotely use is really what they want. This worm does exactly that.
Ah, but that's a very poor analogy. Google isn't Ford. Google's sites are owned and operated by Google. The content on those sites is presented by Google. Up in the title bar of the browser, it says Google.
It may be a poor analogy, but your rebuttal doesn't tell me why you think the analogy is bad. All I'm gathering is that you understand that DNS names and Google are very different things. Unfortunately, I think that many (most?) internet users can't be expected to know exactly how DNS or Google works, only how to use them. When people type a company name into Google, they expect information about that company, and presenting them with a competitor's information can be confusing. This expectation makes it very similar to DNS. I realize that they are entirely different things, and I understand your point.
On the other hand, if you were to click on a clearly marked advertising link, it would take you somewhere else. What's the surprise here?
"Clearly marked"? In Google's case, that's debatable. It uses the vague term "Sponsored Links", but doesn't say who sponsored them.
Advertising on many websites is contextual--should Amazon eliminate its "People who bought this book also bought X" links? Will Stephen King sue because this 'associates' him with Dean Koontz?
I realize that there is a limit to this complaint. However, there is a slight difference in that scenario, because Amazon is simply presenting factual information, whereas Google is allowing other companies to advertise (and therefore make money) using someone else's name.
Personally, I don't think Google should be held responsible. The similarity to domain names makes me believe that the matter should be settled between the advertising firm and AXA. Google seems to have a reasonable policy when it comes to buying ads for trademarks.
If "AXA" wins, this means that using its name is forbidden, unless the company gives its approval beforehand. This imposes an undue restriction on freedom of speech, since Google is certainly not the only forum in which AXA is discussed and/or searched. Will this company sue, let's say, every newspapers or forums that discuss insurance companies and/or policies? Unlikely.
It's slightly more complicated. The problem with Google's ads (as explained by Playboy's lawyer in this article) is that they confuse the user into thinking that the company that they searched for sponsored the ad. Don't confuse it with an effort to eliminate AXA from all web pages everywhere.
It's very similar to domain name squatting. If you go to www.ford.com, you expect to find a company named Ford (most likely Ford motor company), not a redirect to www.honda.com. If you instead found information about a competitor, you might think that the company supports the competitor, which is does not. When you think of this case as if it were about a domain name, it doesn't appear to be as simple as others present it.
How can a workaround/extension of a filesystem to implement a feature that was in other filesystems for decades be not obvious? Despite what this AC might think, long filenames weren't invented by Microsoft.
By that logic, any implementation of an airplane would be obvious and undeserving of a patent, since birds have flown for ages.
As an AC has already said, it's the implementation that is patented, not the idea.
Why would MS buy Sun? Sun has virtually Zero technologies that MS would care about.
I wouldn't say that..Net is (supposed to be, anyway) a J2EE competitor. While the actual code may not be terribly useful to Microsoft, the ideas and intellectual property used in Java and J2EE could be applied to C# and.Net. Also, if Microsoft owned the competition to.Net, it could cannibalize it and eliminate it from the market, making the.Net platform look a lot better to developers, companies, and users. That would help to maintain the monopoly that MS enjoys. As another poster pointed out, though, that move would probably raise antitrust concerns once again.
Granted, I don't think their Unix-related IP is of interest to Microsoft.
This is not a recommended pattern. Once an instance of Slut is created, the same instance is used for every call. Thus, *every* Geek object is going to be using the *same* instance of Slut, and you could end up... um... unprotected from any bugs that exist in the other Geeks.
To avoid unintended tight coupling (AKA shotgun wedding) of yourself to the girl in question, it is always considered prudent to use a wrapper around the interface.
I was thinking that a few others might come in handy:
Facade: Lie to them so they'll be impressed. Interpreter: Learn to understand the ladies and what they're really trying to say. Warning: this is hard. Memento: Give them gifts so you don't look like a cheap bastard. Command: You should probably let her use this pattern.
Slashdot Mirror
If you sold software for money, would you write anything Vista-only?
That depends. Am I Microsoft?
Erm, are you stalking me? :(
No, I just read a few of your comments in "ITMS Faces Complaint From Norwegian Ombudsman".
Shut your face stupid yankee.
He's Norwegian. It's not like the U.S. has a monopoly on France-bashing, you know.
Did you watch the program? I didn't, but am curious how it was presented.
No, I didn't have the opportunity. I'm hoping that I'll be able to find it online. From what I understand, it was pretty fair. Even the left-wing dailykos.com's summary seems to indicate that it was balanced, which is somewhat surprising, given their venomous attitude toward Republicans and their apparent love for hyping the "right-wing conspiracy theory du jour".
Not sure I agree that atrocities were committed to Sinclair. They really went out on a limb to broadcast this news program, and it seemed that the "Under Fire" program was the initial concern, the final program just a last minute CYA. It is unusual for them to produce a news program, and really opened the door for the critism they received. And it was a no win situation. If they presented either candidate in a negative light, that candidate's supporters would cry foul. The fact that they have more history as a partisan supporter than as news organization caused the outrage and the allegations.
Oh, I wasn't trying to say that, literally, atrocities were committed against Sinclair. It's not like they were publicly flogged or anything like that.
I do think that they were prematurely attacked and the media's coverage of it was misleading. Sinclair was fairly quick to respond, saying that the program's content was still being decided and any characterization of the program was premature. I knew that the program would probably be unpolished, given that they hadn't finished it until the last minute. At the very most, I could understand it if a group of people publicly threatened to boycott them if the program was too biased. Instead, people immediately took action against Sinclair as soon as the story broke, and Sinclair received, and is still receiving, much more than just criticism. Call me crazy, but I believe that someone has to do something wrong before they're punished for it.
I'm not sure if Sinclair actually planned to air an hour-long anti-Kerry smear program. That's entirely possible. But I think the media's coverage and public outcry was enough to dissuade them from that alleged plan. Instead, things got out of hand. Certain people falsely claimed that they knew that Sinclair was going to broadcast "Stolen Honor", and others claimed that it was officially announced. People protested, Sinclair was boycotted, and their execs were subjected to personal attacks. These aren't "atrocities", but they certainly show that people can easily be influenced to do some awful things.
"Those who can make you believe absurdities
can make you commit atrocities."
--Voltaire
That's a great quote that is highly relevant here. I think the folks that are outraged by the media's reports on this issue need to step back and consider the evidence that supported the allegations, because it was very weak.
Sinclair never publicly announced that it was airing "Stolen Honor" in its entirety, but the media has claimed that it did. Even now, after the airing of the unbiased special, the LA times falsely claims that "Sinclair announced plans to air "Stolen Honor: Wounds That Never Heal," an anti-Kerry documentary". The Washington Post claims that Mark Hyman told them that the entire documentary would be shown unless Kerry agreed to an interview, but a quick review of their articles reveals no quote of Mark Hyman that says that. Ever since this controversy started, Sinclair execs have been claiming that they were not intending to show "Stolen Honor" in its entirety. On October 12, Mark Hyman said that "nothing has been shot" but the media still insisted that they were going to show the whole documentary.
The best evidence of their alleged nefarious intentions were some TV listings (possibly accidental mistakes), a fired employee that said they were discussing airing the documentary (but weren't sure what they were going to air), and the fact that they were considered conservative. For that, their advertisers were harrassed, their investors were contacted with requests to sell their stock, and the execs "endured personal attacks of the vilest nature". It was obvious to me that the media's reports caused things to get out of hand, and the assault upon the demonized Sinclair was incredibly premature.
and I know people that insert guatamalan fire peppers into their anuses, but they aren't representative of the average population.
Hey, you promised that you wouldn't tell anybody about that!
One of the issues I think is that if you incorperate a certain level of sophistication into your code then people who can not program to that level think it is much too complex.
;-]). Perl is highly idomatic with "More Than One Right Way" to do things. Simple perl code is simple and easy to understand; however, the uninitiated will find it next to impossible to understand how the "magic" of some perl modules works. Modules that use things like glob refs, tied data structures, export, and eval to achieve great new additions to the language in ways that seem impossible.
Take perl for example (mostly cuase you said ick
Who is to blame for this? My instinct tells me that it is the novice that should learn the constructs used in the master's code, but I realize that there is a limit. If someone is using a highly advanced language feature to eliminate a few lines of code, then he is probably going overboard. However, if the code is more robust when the feature is used, then the advanced feature is probably warranted. After all, correctness is the #1 priority. Unfortunately, at first glance, the unfamiliar novice will probably not realize the benefits of the advanced feature and will assume it is unnecessary until it has been explained to him/her. This is especially problematic when the novice does not wish to learn the advanced features of a language.
I also think people make a big scene to managers that the previous developer's code was bad simply to make themselves look good. The manager who usually doesn't code says to themselves "Well he must be a great coder if he thinks the previous developer didn't know what he/she was doing."
Another developer cliché is to complain about documentation. Doesn't matter if you write a war and peace size document to explian everything, the next developer is totally not going to read it. The next developer if he/she doesn't understand it simply says "This code is crap". This buys more time to become competent at programming changes and makes them look like a top coder to the credulous manager.
Where in the hell did you learn to write, anyway? How on earth do you expect someone to understand that incomprehensible mess? Your writing style is absolutely atrocious. Are you a native English speaker? I've met two-year-olds with better communication skills. The simple fact that you started a sentence with "Doesn't matter" instead of "It doesn't matter" means that your entire comment is garbage and should be rewritten. Oh, and it's explain, for God's sake. I won't even bother to comment on the lack of commas.
Super programmers often hurt a team more than they help.
Alot of brilliant engineers and programmers are brilliant for a good reason: their brains are wired to intuitively grasp what mediocre programmers need to explicitly think about.
There's a downside to that as well; namely that those individuals do not have the best communications and personal skills.
That doesn't follow. One can find complex things intuitive and have good communication skills. Many people can explain their "intuitive" ideas. Those are the _real_ super programmers.
You're attacking a strawman.
Sometimes I want to know, as I'm writing my code, exactly what low-level operations will occur when that code gets run. My code, not the libraries I'm calling. Java doesn't even let me do that.
It's a pretty rare "sometimes", though -- I don't do so much low-level work these days. As far as the why of the matter, I think someone wrote a paper about leaky abstractions that explains it pretty well.
It's not a straw man because the original post said it differently. The key word present now that was not originally present: sometimes. You even admit that it's very rare that one would want to know what low-level operations are involved when executing code, and that's very damaging to your original claim that certain people need to avoid back boxes altogether. In actuality, such people would skip Java, Python, and C and opt for assembly code.
The thing is, one could take that "my code" comment to the extreme and say that it is no longer "my code" when it is run through a compiler that might optimize it, or, to take it even further, it is no longer "my code" when it is not written in zeros and ones. You're dealing with abstraction wherever you turn, so let's not pretend that intepreters are so different from compilers.
That "leaky abstractions" paper you're referring to was very weak. It was written by Joel (of "Joel on software") and it was just about the worst material of his that I'd ever read. He even went so far as to claim that the performance of an abstraction can make it leaky, which rendered the definition of "leaky abstraction" pointless, because the implementation of an abstraction would have to run in no time at all to avoid being leaky. No implementations run in no time at all, so every abstraction is leaky, so the definition of "leaky" is worthless because it adds no new meaning to the term abstraction. It was a paper that appeals to programmers who simply don't like abstractions and want to stick to lower-level languages and in-house libraries.
I, sir, have the people skills of a phicus plant.
If you instead had the skills of a ficus I'd vote for you.
Errors indicate a serious virtual machine malfunction.
What you are describing is actually VirtualMachineError, not Error. The Error class is merely for exceptions that you probably won't want to catch. OutOfMemoryError is derived from VirtalMachineError, but that's probably not a good idea, considering that the other classes derived from that class (InternalError, UnknownError, StackOverflowError) are far more serious.
While OutOfMemoryErrors are surely more common while allocating large amounts of memory, they can also occur during the allocation of small objects in which case your options to handle them may be seriously reduced.
While that seems to be the case at first glance, once you take unwinding of the stack and the execution of finally blocks (as well as the unlikeliness that the error will even be thrown when allocating a small object) into consideration, it becomes apparent that it is extremey unlikely that handling an OutOfMemoryError will prove to be difficult unless that handling uses a lot of memory, which would be foolish, given the type of error that occurred.
IHMO, the reason that handling an OutOfMemoryError may be difficult has little to do with the need to allocate memory within the handling code. The simple fact is that most Java code was not written with OutOfMemoryErrors in mind and assumes that the application will terminate when one occurs. This assumption is hardly ever documented. Unfortunately, a lot of server-side code has to remain running even when such errors occur. Unless the code specifically documents the fact that OutOfMemoryErrors are handled gracefully, then you have to assume that the internal state of the objects used could be corrupted.
As an example, consider a method that must update two Hashtables inside of an object, and it is required that both succeed (updating only one would violate the contract provided by the object). In most Java code, if the first update succeeds, and the second fails due to an allocation failing (possible but unlikely), the object's state will be corrupted. After an OutOfMemoryError, figuring out what state your application is in can be hard, if not impossible, unless every piece of the executing code does not assume that OutOfMemoryErrors are grounds for termination.
It could be that I'm taking out of memory conditions too seriously. I did come from a C++ background, and C++ programmers tend to write their code with low memory conditions in mind. Java programmers, on the other hand, seem to mostly ignore memory allocation failures.
The demos are really cool. But the biggest issue, which I think is apparent in the demos also, is that you get these frame rate drops. The best I can tell from playing around with Java3D, this happens because the API is allocating a bunch of objects during rendering. The garbage collector has to come by and get rid of them and it takes long enough to release the unused objects that it interferes with the rendering thread. This turns out to be down right distracting in animation.
What? I've used Java3D, and it seems to me that they went through great pains to ensure that nothing is allocated unless you ask it to be allocated. You're right, the GC can interfere with the rendering thread, but I've never had an issue with the Java3D library causing the GC to kick in. In fact, the Java3D API can look a little awkward when you're used to APIs that are not so sensitive about allocation. They usually design their APIs so you can reuse previously allocated objects. That way, you don't have to release them to the GC, and your performance is more predictable.
For an example of this, examine the GeometryArray class. First, note that it is highly mutable. Everything about the object can be modified, so you never have to create another instance if you already have a spare one lying around. Also, take a look at how all of the setXXX() functions are overloaded so you never have to allocate an object to call the setter. While the API could have just provided one set() method and required you to create an object of the correct type to call it, they decided to instead overload it for any reasonable type that could be used to represent that property.
Are you sure that it's Java3D that's allocating the objects and not the code you wrote?
WebSphere Portal 5 bundled in some web based word/excel replacements. I think the idea was "use our portal, and use us to view (and edit) business content. You don't need office!" The reality was less than inspiring. I'd put it on par with the large number of RTF/HTML editors out there - clunky. Not sure why they did not put their weight behind OpenOffice, because it is head and shoulders above what they included with the Portal.
I think you've got it. Most everyone else is thinking that it's a Java-based solution, but I've seen the software bundled with Portal as well, and I think that this article might be about those editors. You're right, they are a tad clunky, but they don't require a JVM and, according to IBM, they work on many different browsers. It was the furthest I'd ever seen Javascript pushed, and I was surprised that they had the guts to go that far with the language.
[In reply to my statement "No software design should be solely based on English expressions."]
If you believe that, you're a moron.
Forget about 'english'. If you can't express a design in plain natural, human, language, the design is fit for nothing other than the garbage.
Instead of criticising, why don't you come up with an alternative, then maybe you'd be worth wasting time on.
Ah, I knew someone would misinterpret what I said. I was trying to say that no software design should be solely derived from some plain-language description of a problem that has no basis in programming concepts. That is what is commonly done in the "OO beginner" software (e.g. "A car is a vehicle, so we will make the car class derive from the vehicle class"). I was not trying to say that it is best if software designs are impossible to express in plain language. That would be silly.
I advocate designing your objects for flexibility and maintenance. I don't like justifications of object relations that are little more than "Well, of course Foo inherits from Bar because a Foo is a Bar. Don't you get it?" Instead of doing that, I like to take a similar approach to the one Design Patterns use. They create objects and object relations based on coupling issues and what is likely to change, not because they get a warm fuzzy feeling when they say "is a" between the class names.
In college, many moons ago, I was taught a simple rule for determining whether to use composition or inheritance:
This is the "Dummy's Guide To OO" explanation of inheritance and composition. It should only be used to explain these concepts to someone unfamiliar with the terminology. As an AC pointed out, these are definitions, not guidelines for design. No software design should be solely based on English expressions.
Other virus's do all sorts of nasty things, but they all seem to stop short of REALLY bad things. Search for files they can delete, look for a network drive and have their way, find interesting files and mail to random people, rename this or that to render the machine useless.....
A useless machine is... well, useless. Unless the author gets off on chaos, it's pointless to disable the machine. A zombie that you can remotely use is really what they want. This worm does exactly that.
Ah, but that's a very poor analogy. Google isn't Ford. Google's sites are owned and operated by Google. The content on those sites is presented by Google. Up in the title bar of the browser, it says Google.
It may be a poor analogy, but your rebuttal doesn't tell me why you think the analogy is bad. All I'm gathering is that you understand that DNS names and Google are very different things. Unfortunately, I think that many (most?) internet users can't be expected to know exactly how DNS or Google works, only how to use them. When people type a company name into Google, they expect information about that company, and presenting them with a competitor's information can be confusing. This expectation makes it very similar to DNS. I realize that they are entirely different things, and I understand your point.
On the other hand, if you were to click on a clearly marked advertising link, it would take you somewhere else. What's the surprise here?
"Clearly marked"? In Google's case, that's debatable. It uses the vague term "Sponsored Links", but doesn't say who sponsored them.
Advertising on many websites is contextual--should Amazon eliminate its "People who bought this book also bought X" links? Will Stephen King sue because this 'associates' him with Dean Koontz?
I realize that there is a limit to this complaint. However, there is a slight difference in that scenario, because Amazon is simply presenting factual information, whereas Google is allowing other companies to advertise (and therefore make money) using someone else's name.
Personally, I don't think Google should be held responsible. The similarity to domain names makes me believe that the matter should be settled between the advertising firm and AXA. Google seems to have a reasonable policy when it comes to buying ads for trademarks.
If "AXA" wins, this means that using its name is forbidden, unless the company gives its approval beforehand. This imposes an undue restriction on freedom of speech, since Google is certainly not the only forum in which AXA is discussed and/or searched. Will this company sue, let's say, every newspapers or forums that discuss insurance companies and/or policies? Unlikely.
It's slightly more complicated. The problem with Google's ads (as explained by Playboy's lawyer in this article) is that they confuse the user into thinking that the company that they searched for sponsored the ad. Don't confuse it with an effort to eliminate AXA from all web pages everywhere.
It's very similar to domain name squatting. If you go to www.ford.com, you expect to find a company named Ford (most likely Ford motor company), not a redirect to www.honda.com. If you instead found information about a competitor, you might think that the company supports the competitor, which is does not. When you think of this case as if it were about a domain name, it doesn't appear to be as simple as others present it.
How can a workaround/extension of a filesystem to implement a feature that was in other filesystems for decades be not obvious? Despite what this AC might think, long filenames weren't invented by Microsoft.
By that logic, any implementation of an airplane would be obvious and undeserving of a patent, since birds have flown for ages.
As an AC has already said, it's the implementation that is patented, not the idea.
Even at that though, is distribution defined clearly? Does it count if a company distributes the binaries for a tool within its own company?
This is addressed in the FAQ. See "Is making and using multiple copies within one organization or company "distribution"?"
Why would MS buy Sun? Sun has virtually Zero technologies that MS would care about.
.Net is (supposed to be, anyway) a J2EE competitor. While the actual code may not be terribly useful to Microsoft, the ideas and intellectual property used in Java and J2EE could be applied to C# and .Net. Also, if Microsoft owned the competition to .Net, it could cannibalize it and eliminate it from the market, making the .Net platform look a lot better to developers, companies, and users. That would help to maintain the monopoly that MS enjoys. As another poster pointed out, though, that move would probably raise antitrust concerns once again.
I wouldn't say that.
Granted, I don't think their Unix-related IP is of interest to Microsoft.
This is not a recommended pattern. Once an instance of Slut is created, the same instance is used for every call. Thus, *every* Geek object is going to be using the *same* instance of Slut, and you could end up... um... unprotected from any bugs that exist in the other Geeks.
To avoid unintended tight coupling (AKA shotgun wedding) of yourself to the girl in question, it is always considered prudent to use a wrapper around the interface.
Singleton... definately the Singleton pattern.
I was thinking that a few others might come in handy:
Facade: Lie to them so they'll be impressed.
Interpreter: Learn to understand the ladies and what they're really trying to say. Warning: this is hard.
Memento: Give them gifts so you don't look like a cheap bastard.
Command: You should probably let her use this pattern.