Patenting a time machine is a waste of time and money. If someone succeeds in building one, he (or she) will travel back to day before you patented it.
But since we're talking about future development: how far are we from the day when we can read spinal impulses and then make "our body" react to them?
I'm thinking about people who can't walk for spinal damages.. their impulse can be read and trasmitted to electrodes that would make their muscles move, their legs walk, their hands grab objects.
> Usually, IMO, performance tuning, when it requires altering the storage schema, is done using one of two methods:
> 1) Denormalization
> 2) Higher normal forms
> 3) Summary tables
I agree with you if you mean that these are the tricks the (optimal) RDBMS could use "under the cover" to optimize the access plan (making them "transparent" to the application).
Let's take the "Denormalization" as an example:
we have two entities A and B that are loaded once a day with a batch. We know that they're mostly joined together in the queries.
My idea of an "optimal" RDBMS is that I can define the two entities and the application can query them individually or joined together.
Then I decide to start the "tuning" phase and I give the RDBMS an "hint" to change the physical layout of the data and keep them just in a single "data store".
I keep inserting tuple in A,B entities and the RDBMS would keep the "abstraction" of two indipendent entities.
The joined query (that is the more frequent) can get the data from the 2 entities from the same blocks. If the application evolves in a way that the individual queries become more frequent I'd have to "revoke" the hint and separate the datastores WITHOUT changing the application.
The SQL RDBMS are beginning to have these features (what I describe here is more or less the Oracle CLUSTERED TABLE) but on other databases the solution is to change the logical schema when they just want to change the phisical layout of the data.
At a first glance of the specs, it seems that Adobe is proposing something more than a "RAW" format.
They're filling the format with lots of structured metadata that can give you all the information you need (and probably also some you don't need:-) about the photo AND the settings of the camera (which lens you used, which model, and every other setting I don't know anything about).
You could look at a photo and say "Hey, I like the way the details are emphasized in this photo. Let's see which settings he used".
Compression: they're proposing a "lossless JPEG" compression. Since they cited the DCT-based compression (for lossy compression), I guess that the "lossless JPEG" will be the "old" one and not the JPEG2000 wavelet based format (probably to avoid heavy modifications to today firmware).
My opinion is that the main feature of this format is the presence of photo-specific metadata (while JPEG2000 is "general-purpose"), but it probably could have been substituted by a "sub-specification" of the JPEG2000 metadata.
When I was in University there was an old professor who gave us to write relation about JPEG format with code examples...
When we were leaving his room he gave us this advice: "Beware the JPEG virus". It was 9 years ago and he was quite old and sometimes he acted/talked nonsense so we made fun of his advice (we thought: since it was not an executable file, how could it bring a virus): but he was right and we were wrong..
I'm not meaning that "operator overloading" is BAD and therefore we should always limit it (I used C++ and I was happy with "operator overloading" and I feel I never abused it)
I'm just saying that Java (the language) direction has always been for exchanging "flexibility" for "maintanability" and therefore "operator overloading" could be introduced in Java only following the same path.
Someone pointed out that a language cannot prevent the inexperienced developer to abuse a feature: that's absolutely true, but a language can try to make easier for the experienced developer to find and repair the damages with little effort.
When we feel the flexibility and elegance is more important than this kind of "maintanability" we will choose other languages.
P.S.: I'm using "maintanability" but the concept is more like "allowing the experienced developers to compensate for the inexperienced ones". My knowledge of English doesn't allow me to find a better word:-( I guess it is something similar to what managers call "productivity":-)
1) I noticed I went slightly offtopic.. (sorry) The original question was "what can I use to make numerical analysys?" while I followed the track "Operator overloading is good/evil"
2) the sentence "I'm not going to" was "I'm not going to misuse this feature"
Could we please try lo list why "operator overloading" is such a troublesome feature?
The statement "since it is so easy to misuse" doesn't count: I'd like to know WHY it is so easy to misuses.
The statement "you'd better use other languages for mathematical calculus" doesn't apply either: I'm in a financial project and we use Java, and there are some pretty complicate expression even in economics.
The statement "I used it in C++ and it was a mess" is also not appropriate as an answer to my question: if Java will ever consider this feature, there's no reason why it should copy the C++ style.
On the other side (the operator overloading fans): the statement "I'm not going to" doesn't apply; your colleague could do and you would kill him after tracing a bug
The statement "The expressive power of this feature is more important than the possible misuses" doesn't apply either: Java tries to avoid misuses by forcing programmers to behave properly and we should respect this philosophy (not meaning I'm against the feature.. only I'd like to have it without the major cons)
My opinion: "Why it is so easy to misuse and mantain?"
1) At first glance you could not realize if the symbol "+" is a simple primitive "sum" or a more elaborate object operator
2) sometimes the notation is simply "out of this world" (ehm... meaning "not natural":-)
Example: (let me write in pseudo-Java) Vector v1=new Vector(); Vector v2=new Vector(); Vector v3=v1+v2;//ok, concatenation of the 2 vectors Vector v4=v2-v1;//what the hell does that mean?
3) if we choose a C++-like implementation we could have a "operator+" (-/*) method that has its own implementation (possibly different from add() or any other method in the class)
4) if we choose a C++-like implementation we wouldn't have just one place to look at to understand the meaning of operators (they could be overloaded twice or more times in the class hierarchy)
Any other reason in your opinion? Then when we have all the reasons listed we could consider if there could be a way (compatible with "Java guidelines") to add this feature without incurring in all this misuse problems.
If we (or Sun:-) can't find such a way, or is not justified by the advantages (cleaner syntax in economics and mathematical expression) then we would not ask for it...
A car company recalls their last car model for defective brakes only to their higher profit customer. The warning for the normal customer will be issued 2 weeks later... </joke>
Every company has the right to give "preferential treatment" to its higher profit customer.. but we're not talking about discount or special offers.. we're talking about defects and vulnerabilities and I guess all the customer have the same right to know it they're using an unsafe environment.
On the other side, as stated on the article, it makes perfect sense to warn "critical infrastructure company" before releasing information that could be used by malicious users.
"...However, many of the detectors we have implemented, such as inconsistent synchronization and mutable static fields, are not present in PMD. Like our tool, PMD uses Visitors to implement its pattern detectors. One nice feature of PMD is that patterns may be implemented as XPath expressions, so that new checks can be added without the need to write a new Visitor class...."
I'm wondering if they mean that their "detectors" (inconsistent synchronization and mutable static fields) can't be written in PMD XPath...
Otherwise I don't see it as a PMD problem.. they could easyly contribute two new PMD rules and everyone could use them..
Let's hope they (or the PMD devolepers) will soon contribute that.
Code written under extreme management pressure from a profit-hungry megacorp is just as bad as code written by an ignorant or uneducated dork in his basement.
Excellent point, but I should add, imho, that while I'm not forced to join an open source project, I could be forced to work with "shittish" projects under "extreme management pressure".
If an open source project is badly architectured, horribly coded and everything else, it simply fades away and disappears. Sometimes, the megacorp project still arrives in production phase and is sold thanks to great marketing ideas.
So, sometimes the code is "just as bad" but the
megacorp one would make more damages.
It seems to me that it is an optimized PayPal. I mean "merchant-side" optimized (they can "group" micropayments to save on transaction fee).
"I thought the major factor with services with Paypal etc. was that users don't want to have to sign up with a 3rd party - it's just too much hassel."
You are already dealing with a 3rd party.. the Credit Card company; only you don't notice 95% of
the times.
If Peppercoin succeeds in making themselves perceived as "transparent" to users, they could be succesful. Anyway, I guess that if micropayments becomes a rich business, Credit Cards companies will take the business in their hands.
The risk is that customers use Office *now* because they choose it *yesterday* cause it was the best Office suite : today they just can't use any other suite because they can't share files with others...
I don't call it "being the best on the basis of price and features"... it's purely monopolistic advantage..
Think how the Internet would have looked like if, instead of HTML, we have had HDOC proprietary Microsoft format..
but you can't exactly accuse Microsoft of resting on its laurels
Absolutely.. the problem is that a lot of times
they should have thought about making the OS faster and safe.
Instead they kept putting in their OS features
nobody asked for, increasing CPU speed demand and RAM hunger...
They think in terms of
"the Next Product to sell to the customer", instead of trying to make it "really" good.
I don't mean that's just a Microsoft problem..
but since they're a sort of monopoly, people are
going to suffer a lot more from Microsoft mistakes than from the mistakes of the rest of IT industry..
Slashdot Mirror
"Etch-a-skecth"-like clear function? :-)
P.S.: by the way, I wouldn't suggest associating any particularly destructive command (clear, delete, format, etc) to the "knock" shortcut.
Patenting a time machine is a waste of time and money. If someone succeeds in building one, he (or she) will travel back to day before you patented it.
I had the misfortune to work with a third-party software who had its own programming language, IDE and "repository" (it was on a database).
We hadn't any "offical" way to export and then import the code from the db and the "versioning" function provided by the IDE wasn't useful at all..
I hope it is rare to be in this situation now.
But since we're talking about future development: how far are we from the day when we can read spinal impulses and then make "our body" react to them?
I'm thinking about people who can't walk for spinal damages.. their impulse can be read and trasmitted to electrodes that would make their muscles move, their legs walk, their hands grab objects.
Ok.. I must stop seeing sci-fi films :-)
Sorry... I should have previewed the message..
> Usually, IMO, performance tuning, when it requires altering the storage schema, is done using one of two methods: > 1) Denormalization > 2) Higher normal forms > 3) Summary tables I agree with you if you mean that these are the tricks the (optimal) RDBMS could use "under the cover" to optimize the access plan (making them "transparent" to the application). Let's take the "Denormalization" as an example: we have two entities A and B that are loaded once a day with a batch. We know that they're mostly joined together in the queries. My idea of an "optimal" RDBMS is that I can define the two entities and the application can query them individually or joined together. Then I decide to start the "tuning" phase and I give the RDBMS an "hint" to change the physical layout of the data and keep them just in a single "data store". I keep inserting tuple in A,B entities and the RDBMS would keep the "abstraction" of two indipendent entities. The joined query (that is the more frequent) can get the data from the 2 entities from the same blocks. If the application evolves in a way that the individual queries become more frequent I'd have to "revoke" the hint and separate the datastores WITHOUT changing the application. The SQL RDBMS are beginning to have these features (what I describe here is more or less the Oracle CLUSTERED TABLE) but on other databases the solution is to change the logical schema when they just want to change the phisical layout of the data.
I thought we were talking about RAW format as in normal computer imaging, with all the image data in the less-compressed form...
Thank you for pointing out my mistake...
It seems I mixed contexts... (sorry)
I meant Vector as in Java libraries, that is "a Collection". I should have used "List" instead.
I wanted to say that sometimes "operator overload" is used out of maths/economics context and this is sometimes confusing
At a first glance of the specs, it seems that Adobe is proposing something more than a "RAW" format.
:-) about the photo AND the settings of the camera (which lens you used, which model, and every other setting I don't know anything about).
They're filling the format with lots of structured metadata that can give you all the information you need (and probably also some you don't need
You could look at a photo and say "Hey, I like the way the details are emphasized in this photo. Let's see which settings he used".
Compression: they're proposing a "lossless JPEG" compression. Since they cited the DCT-based compression (for lossy compression), I guess that the "lossless JPEG" will be the "old" one and not the JPEG2000 wavelet based format (probably to avoid heavy modifications to today firmware).
My opinion is that the main feature of this format is the presence of photo-specific metadata (while JPEG2000 is "general-purpose"), but it probably could have been substituted by a "sub-specification" of the JPEG2000 metadata.
When we were leaving his room he gave us this advice: "Beware the JPEG virus". It was 9 years ago and he was quite old and sometimes he acted/talked nonsense so we made fun of his advice (we thought: since it was not an executable file, how could it bring a virus): but he was right and we were wrong..
"Why it is so easy to misuse and mantain?"
was
"Why it is so easy to misuse and hard to mantain?"
I'm not meaning that "operator overloading" is BAD and therefore we should always limit it (I used C++ and I was happy with "operator overloading" and I feel I never abused it)
:-( :-)
I'm just saying that Java (the language) direction has always been for exchanging "flexibility" for "maintanability" and therefore "operator overloading" could be introduced in Java only following the same path.
Someone pointed out that a language cannot prevent the inexperienced developer to abuse a feature: that's absolutely true, but a language can try to make easier for the experienced developer to find and repair the damages with little effort.
When we feel the flexibility and elegance is more important than this kind of "maintanability" we will choose other languages.
P.S.: I'm using "maintanability" but the concept is more like "allowing the experienced developers to compensate for the inexperienced ones". My knowledge of English doesn't allow me to find a better word
I guess it is something similar to what managers call "productivity"
1) I noticed I went slightly offtopic.. (sorry)
The original question was "what can I use to make numerical analysys?" while I followed the track "Operator overloading is good/evil"
2) the sentence "I'm not going to" was "I'm not going to misuse this feature"
Could we please try lo list why "operator overloading" is such a troublesome feature?
:-)
//ok, concatenation of the 2 vectors //what the hell does that mean?
:-) can't find such a way, or is not justified by the advantages (cleaner syntax in economics and mathematical expression) then we would not ask for it...
d =4905919
The statement "since it is so easy to misuse" doesn't count: I'd like to know WHY it is so easy to misuses.
The statement "you'd better use other languages for mathematical calculus" doesn't apply either: I'm in a financial project and we use Java, and there are some pretty complicate expression even in economics.
The statement "I used it in C++ and it was a mess" is also not appropriate as an answer to my question: if Java will ever consider this feature, there's no reason why it should copy the C++ style.
On the other side (the operator overloading fans):
the statement "I'm not going to" doesn't apply; your colleague could do and you would kill him after tracing a bug
The statement "The expressive power of this feature is more important than the possible misuses" doesn't apply either: Java tries to avoid misuses by forcing programmers to behave properly and we should respect this philosophy (not meaning I'm against the feature.. only I'd like to have it without the major cons)
My opinion:
"Why it is so easy to misuse and mantain?"
1) At first glance you could not realize if the symbol "+" is a simple primitive "sum" or a more elaborate object operator
2) sometimes the notation is simply "out of this world" (ehm... meaning "not natural"
Example: (let me write in pseudo-Java)
Vector v1=new Vector();
Vector v2=new Vector();
Vector v3=v1+v2;
Vector v4=v2-v1;
3) if we choose a C++-like implementation we could have a "operator+" (-/*) method that has its own implementation (possibly different from add() or any other method in the class)
4) if we choose a C++-like implementation we wouldn't have just one place to look at to understand the meaning of operators (they could be overloaded twice or more times in the class hierarchy)
Any other reason in your opinion?
Then when we have all the reasons listed we could consider if there could be a way (compatible with "Java guidelines") to add this feature without incurring in all this misuse problems.
If we (or Sun
Last thing:
you can vote for this feature (or stand against it ) at this URL (registration needed) http://bugs.sun.com/bugdatabase/view_bug.do?bug_i
A car company recalls their last car model for defective brakes only to their higher profit customer.
The warning for the normal customer will be issued 2 weeks later...
</joke>
Every company has the right to give "preferential treatment" to its higher profit customer.. but we're not talking about discount or special offers.. we're talking about defects and vulnerabilities and I guess all the customer have the same right to know it they're using an unsafe environment.
On the other side, as stated on the article, it makes perfect sense to warn "critical infrastructure company" before releasing information that could be used by malicious users.
I don't agree too much with your.. "but Barrichello isn't doing as good."
http://www.formula1.com/archive/driver/2004.html
He is the second pilot in the ranking and he has 21 points more than the third...
So, even if Schumacher wasn't the great champion he is, we would have anyway a Ferrari driver in the first place.
Obviously, the pilot contributes also to the development and fine tuning of the car.
Ferrari makes Schumacher unbeatable, but Schumacher makes Ferrari unbeatable...
"...However, many of the
detectors we have implemented, such as inconsistent
synchronization and mutable static fields, are not
present in PMD. Like our tool, PMD uses Visitors
to implement its pattern detectors. One nice
feature of PMD is that patterns may be implemented
as XPath expressions, so that new checks can be
added without the need to write a new Visitor
class...."
I'm wondering if they mean that their "detectors" (inconsistent synchronization and mutable static fields) can't be written in PMD XPath...
Otherwise I don't see it as a PMD problem.. they could easyly contribute two new PMD rules and everyone could use them..
Let's hope they (or the PMD devolepers) will soon contribute that.
I don't know if that's the case, but we've heard of "old classics" that are going to have a new life thanks to "cell-phone" porting.
:-)
What about playing DM on your java-enabled phone?
(disclaimer: I'm not going to
Code written under extreme management pressure from a profit-hungry megacorp is just as bad as code written by an ignorant or uneducated dork in his basement.
Excellent point, but I should add, imho, that while I'm not forced to join an open source project, I could be forced to work with "shittish" projects under "extreme management pressure".
If an open source project is badly architectured, horribly coded and everything else, it simply fades away and disappears. Sometimes, the megacorp project still arrives in production phase and is sold thanks to great marketing ideas.
So, sometimes the code is "just as bad" but the megacorp one would make more damages.
May I add that they've created an excellent "stand-alone syntax highlighting text editor JavaBean." (jedit-syntax at sourceforge)?
:-)
I wanted to add "scripting support" to my application, but I wanted to have syntax highlighting (so it looked more professional
I had to change 5 lines of my code and I had my syntax highlighting editor.
A really useful component and an excellent example of "component-based reuse".
P.S.: maybe it's just a bit off-topic, but since we're developers I guess it's still an useful info.
"I thought the major factor with services with Paypal etc. was that users don't want to have to sign up with a 3rd party - it's just too much hassel." You are already dealing with a 3rd party.. the Credit Card company; only you don't notice 95% of the times.
If Peppercoin succeeds in making themselves perceived as "transparent" to users, they could be succesful. Anyway, I guess that if micropayments becomes a rich business, Credit Cards companies will take the business in their hands.
I don't call it "being the best on the basis of price and features"... it's purely monopolistic advantage..
Think how the Internet would have looked like if, instead of HTML, we have had HDOC proprietary Microsoft format..
Absolutely.. the problem is that a lot of times they should have thought about making the OS faster and safe.
Instead they kept putting in their OS features nobody asked for, increasing CPU speed demand and RAM hunger...
They think in terms of "the Next Product to sell to the customer", instead of trying to make it "really" good.
I don't mean that's just a Microsoft problem.. but since they're a sort of monopoly, people are going to suffer a lot more from Microsoft mistakes than from the mistakes of the rest of IT industry..
And there are some other people that use Office simply because:
1 - everyone else uses Office and they have to share documents.
2 - they haven't heard of anything else.
I don't know if these are just a small minority, but they exist..
There are situations when you'd like to let somebody know exactly where you are...
The problem is that, even if such a tecnology will be developed in 10 years, it won't become "common" since it will be too complicate to "filter".
Ok.. there's another possibility.. people could use "default settings" not noticing they've said farewell to their privacy.. :-(