A theory about that statement I make is that there is an equal amount of matter as there is anti-matter.
Ah, but no, that's one of the great conundrums in cosmology.
Current theories are that after the Big Bang there were equal amounts of matter and anti-matter, but not quite. For some unknown reason, there was a very tiny fraction more matter than antimatter. The antimatter annihilated the matter, except for the the tiny fraction of matter. And that tiny fraction makes up the known universe...
If there were exactly the same amounts of matter and antimatter, they would annihilate given enough time.
So, it's very unlikely that there is antimatter "out there".
Ah, no, you're not the only one. It should be rather obvious. The whole point is that antimatter is only useful as energy storage. So, you would have to have a cheap energy source, a somewhat efficient way of storing the energy in antimatter, plus a safe and practical way of storing the antimatter (quite a challenge). Unless you could harvest hydrogen in outer space and convert it to anti-hydrogen....
It's very costly to mathematically prove that a program has zero errors...
Here I go in pedantic mode again. It's actually impossible to mathematically prove that a program is correct. It has been mathematically proven that a correctness proof does not exist (meta-proof...).
Notwithstanding all the research on formal correctness assurance methods, when you go to a low enough level (i.e. machine instructions), the methods all fail. As a friend of mine once said: "at least you can prove it's not your fault" , but that's about as far as it goes.
Having said that, NASA's methods are extremely thorough (specify, specify, specify, test, test, test, ad nauseam), and the Space Shuttle's software is probably by far the most reliable in the world.
It is also very unlikely that NASA will ever do anything with most of these research projects.
I think you're absolutely right, however, the one or two research projects that do lead to something useful might actually be very useful. To state the obvious, this is the very nature of scientific research. Look at drug companies: out of a thousand compounds they test, maybe one or two will lead to a marketable drug. However, the one or two might just be the cure for cancer or AIDS, or whatever. If you look at the history of scientific research, you'll find that most revolutionary things came from fundamental research, that never promised to result in anything useful in the beginning. A few examples: low temperature research (superconductors), research into the structure of the atom (nuclear energy, nuclear medicine, and -unfortunately- nuclear weapons), mathematical group theory (error-correcting codes), solid stae physics (transistor->microprocessor->computers->I nternet), etc.
Although I generally agree with you, consider this:
This type of research is very long-term, i.e., you and I will probably never reap the benefits. However, our great-grandchildren might be thankful. We would never have today's technology if our ancestors had not had the courage to dream of great things, and act on their dreams.
Nuclear efficiency is in between. While there is not complete conversion, there is some mass going to energy, unlike in chemical rockets.
Err, no, that is wrong. Chemical reactions transform mass into energy just as nuclear reactions do. It's just that chemical reactions transform a far smaller percentage of mass into energy. So, as you correctly point out, it's an efficiency thing. The reason is that chemical reactions work on the binding energy between electrons, whereas nuclear reactions act on the
atom's nucleus, where energies are magnitudes higher.
It's all rather confusing, since the number and type of particles are the same before and after the reactions, both for chemical and nuclear reactions. However, the assembly of particles have different masses before and after reactions. So where did the mass that was converted come from? Well, just as mass is equivalent to energy, so is energy equivalent to mass. The binding energy in atoms is mass, obeying E=mc^2. And that is the energy/mass that is freed during a reaction, be it a chemical or nuclear reaction.
Side note: one of the more offbeat theories about the Tunguska explosion was that it was a chunk of antimatter, not an asteroid.
Offbeat indeed. Occam's razor: "the simplest explanation is usually the right one"
You don't need antimatter to explain the Tunguska explosion. Even a modest asteroid packs an enormous amount of (kinetic) energy, with the average speed of about 50 km/sec.
To quote The Pragmatic Programmer, by Andrew Hunt and David Thomas: "when you see hoofprints, think horses, not zebras"
The law of conservation of matter has been merged with the law of conservation of energy, and the two are now the law of conservation of matter-energy. All Einstein's fault. It's the famous E=mc^2 equation, that tells us that the conversion ratio between matter and energy equals c^2 [m^2/s^2]. That's a rather high number (~ 9*10^16 m^2/s^2), so we don't really notice the disappearing matter in real life. In other words, yes, matter is annihilated (destroyed), but we rarely notice. Note that this does not just apply to matter/anti-matter reactions, "ordinary" nuclear and chemical reactions obey the same law.
It has been demonstated in lab experiments that the opposite also holds. Given the right conditions and the right amount of energy, you can actually make particle/anti-particle pairs pop up out of nowhere!
The distance to Mars would be 55*10^6 km = 55*10^9 m.
We use a 1 g accelleration all the way. That's the same as on earth. We turn the ship when we're halfway there and start braking with 1 g, so we can actually stop and do some sightseeing on Mars.
Now, assuming we start with a velocity of zero, the equation relating distance and accelleration is:
s(t) = 0.5*a*(t^2),
Where s = the distance in meters, t is time in seconds, and a is accelleration in m/s^2.
One g is approximately 10 m/s^2. s(t) is our halfway distance, or ~ 27.5*10^9 m. Substituting all that results in:
t^2 = 55*10^8, so t ~ 74000 seconds ~ 20.5 hours. That's for the trip halfway, so the total travel time would be around 41 hours = less than 2 days!
The top speed would be an impressive 740 km/s, which is high, but not nearly high enough to get in trouble with Einstein's relativity laws.
So, a few weeks doesn't seem that unreasonable. It's more the anti-matter thing that seems to be the problem.
That's fun, but you're overdoing it. You lose credibility that way. My method consists of your first two steps (i.e., just double it). I usually finish a bit below my estimate that way ("boy, this guy knows how to estimate"). Sometimes I finish a bit over the estimate, but that's generally accepted. My biggest miss was when I estimated three days, and it took only one. I could have goofed around for the remaining two days, but that's not very ethical. Besides, finishing two days ahead of schedule is far easier to sell to your manager than the opposite:-)
Yes. Unfortunately, this idea is not used very often. It is inspired by newspaper deadlines (where deadlines are actually deadlines). Same thing for the TV news.
As far as I know, the only software development area that enforces time boxing is the space business ("if we don't launch this probe by next year, we'll have to wait until the next launch window opens up in 2087"). In other areas, people know that deadlines are flexible, and actually expect release dates to slip.
Agreed. To add a few comments rather than create a new post:
Most projects do not have any algorithmic complexity at all! E.g. a lot of (Web) systems are no more than a GUI on top of a database. Any algorithmic problem (e.g. sorting) is usually already solved in some library or 3rd party tool.
Most developers are pretty good at estimating the time it takes to write a piece of code (as long as it is reasonably clear what the code is supposed to do). The problem is that managers usually don't like the estimate, and pressure the developer to come up with a lower estimate. I can't even count the number of times I heard "that answer is not good enough" (my usual response is to say: "well, at least it's true, so I think it's a pretty good answer").
Unfortunately, many developers do not have the courage to hold their ground and stand up to their manager. This problem is exacerbated by the fact that a slipping schedule is usually accepted, since it happens all the time!
Also, sometimes you simply cannot make a reasonable estimate, since there are too many uncertain factors. Just say "I don't know", it's a perfectly good answer, and a lot better than the answer that your manager wants to hear, but that is based on nothing.
By the way, a good manager will appreciate an honest answer.
Lastly, a lot of problems are caused by technology hype. A manager has read in Business Week that C# (or EJBs, or whatever) is the wave of the future, so that's the way to go. Never mind if it is relevant for the problem to be solved. Developers are even more to blame for this. In 1997 I worked on a brand new project that used Java, Swing (while still in beta), CORBA and an OODBMS. Talk about technology risk! Developers like this stuff
because it is cool, and it's good for their resume. Projects like this usually crash and burn because they lose sight of the fact that at the end of the day you have to make a profit, or else the company will be out of business some day, and you have to look for another job. The solution of course is to go into academic research (doesn't pay a lot) or join the research department of a company like IBM (only few of us are so lucky, though...).
Um, no. Unless I'm terribly mistaken, a Reed-Solomon code is an error-correcting code, especially good at correcting burst errors (think scratches). If it is used for copy-protection, it's the first time I've heard of it.
If I remember correctly, the whole error-correction scheme belongs to Sony.
Really? I don't dare to claim that you are wrong about this, but I can remember (way back when) a Philips researcher visiting my (Dutch) university, explaining all the design decicions behind the choice for the (Reed-Solomon) coding. Could be that they collaborated with Sony on that, but my impression then was that is was all developed by Philips.
Yet the main inventor is Phillips.
I think this is correct. As I remember it, the main reason Philips involved Sony in the CD development in the first place, was that they wanted to get a foot in the door on the Japanese market, to prevent a repetition of the VCR mess (multiple standards). Might have been propaganda by the Dutch media, of course...
Err...I don't think so. Granted, they're all over the world, but they're originally a Dutch company, still headquartered in the Netherlands, and as far as I know is their research lab (which gave us the CD, audio cassette, NiMH rechargeable batteries, electric razors with rotating blades and a whole lot more) also still in the Netherlands.
I'd mod you up as "Informative", but unfortunately I used up all my mod points last night. As a Dutchman living in the US, I share your frustration, I see the misspelling in print as well. Oh well, at least they have an astounding amount of Philips fluorescent lights in this country;-)
Well, excuse my ignorance, but what's the point in having 24 bit 96 KHz? I'm assuming 24 bits applies to the samples, and 96 KHz is the sample frequency. So, that would result in much lower quantization noise, and the ability to reproduce frequencies up to 48 KHz (if Nyquist's law still applies). What speaker is going to reproduce this faithfully? Not to mention the frequency response of your ears? I'm not trolling, I really am curious: did you listen to 24 bit 96KHz audio, and did you really hear a difference with 'plain' CD quality?
Let's face it, folks: there is no right to anonymity.
The Constitution isn't the final yardstick to measure everything against. You could argue that there is at least a moral right to anonymity (as opposed to whatever the Constitution mentions). Ironically enough, the Founding Fathers recognized the fact that they did not hold all wisdom for eternity, and included the concept of amending the Constitution, which has actually happened quite a few times...
Why is that? Are you planning to criticize Berman or G4? Or do you think they'll start prosecuting people who have the audacity to express their non-party-line opinions on their private websites? Couldn't happen in America, could it?
I wonder if this Cyclone makes programming "safer" by making it more difficult. What I mean by this is that some languages out there don't let you use pointers at all, or perform all sorts of checks on array bounds before each access. I like to call this "broken programming" simply because it isn't right in my opinion.
I disagree. Take for example Java, which does not have pointers. That hardly makes programming harder, it's easier if anything. An enormous amount of bugs are related to poor memory management. Most programmers make mistakes here. Array bound checks are pretty useful. Most compilers let you switch them off, so you can develop with array bound checks enabled, and disable them once you're convinced that everything is working right(...).
I like to compare pointers to a chain saw: a powerful tool in the hands of an expert, but most people should not even touch it...
A programmer should have all tools available to him, and should choose the best tool for the job when solving any given problem. Taking away tools doesn't make programming safer--it makes programming messier.
Seems to me that Cyclone is adding a tool rather than taking something away.
I thought this is what Lint is for.
Yes, lint is an excellent tool. Problem is that nobody uses it, unless forced by some project guideline. Worse, I have seen plenty of fools who disable all compiler warnings. Seems like Cyclone is building lint-like capabilities into the compiler, so you're forced to use it. Does not seem like a bad idea to me. My experience is that if you give programmers the opportunity to hose themselves, they will invariably do so.
I think that careful programming and use of a tool like Lint can make a better improvement than taking away some of the most powerful tools in programming just because some people don't know how to use them.
Unfortunately, most people don't know how to use them, or are unwilling to spend the extra effort. Careful programming requires discipline, something that most free spirits in software development are lacking.
Having said all this, I don't think Cyclone will cause a major revolution in programming. Most people are not waiting for Yet Another Language...
I don't know if I agree or not, but it's a valid point. It has been argued that any ET civilization we might contact would likely be far ahead of us technologically, exactly because of the short period that we have been in the technological age. Hostile or not, a civilization that's far ahead of us is likely to be dangerous.
I have worked with VA Java Enterprise Edition v3.5 for almost a year. Some replies and general comments.
Like all IDEs it got it's good points and it's bad point's.
Agreed.
Lots of people don't like the fact that it kinda hides the Java code from the programmer by only displaying one method at a time. I hated this feature when I first used it.
After a while, you'll either really get to like this feature or simply get used to it.
I'm afraid I still hate it. Fortunately, it offers a "Source View" option. This basically displays the code in a more traditional manner (i.e., all methods are displayed in the same window). Two problems with that: 1. It rearranges the order of the methods all the time. I like to have my main method at the bottom of the class, and the constructors at the top. Unfortunately, VA Java has its own ideas of what looks cool. 2. If you want to add a comment section between methods, it gets confused as to which method the comment section belongs. Sometimes it puts it in the right spot, sometimes in the wrong spot, and worst of all, sometimes it completely discards the comment section. So here I am, being a good boy and adding extensive comments, I hit Save and all my work is gone. Comment from the IBM guy on the project: "Don't use that feature".
One of the main reason I like Visual Age is because of its build in code repository. This repository is really usefully for team development (much easier/faster then cvs).
I can't comment on CVS, but VAJ's versioning/CM sure is a lot worse than ClearCase. The versioning is sort of OK. Every save operation creates a new (timestamped) version, so you can always go back (nice). Side effect is that the repository file becomes rather large pretty quickly (several hundreds of MBs). However, when doing explicit versioning, the version numbering is totally left to the developer, as long as the version does not already exist. You think version 1.2.1 is newer than version 1.1.6? Well, probably, but not always. Strange surprises can happen here.
The main problem is with defining a configuration (or "solution" in VAJ lingo). Every package version and possibly every class version needs to be hand-picked(ClearCase lets you define sophisticated selection rules. Once that is done, building a configuration is automatic). This may not seem to be a big deal, but my experience is that it became a maintenance nightmare quickly. And we only had half a dozen developers. We had one guy waste 2 weeks because he had been working on the wrong versions. The rest of the team spent more time futzing around with the CM system than with cutting code.
To IBM's credit, VAJ does offer 3rd party CM tool integrations. Unfortunately, the ClearCase integration turned out to be buggy and unreliable.
Merging code that more then one person worked on couldn't be simpler.
I must have missed something here. I found it to be cumbersome. Could be me, though (no sarcasm intended).
It's debugger is far ahead of anyone elses.
Agreed. Sometimes it got a little confused, but that's a minor complaint. Overall, the debugger is truly excellent.
You can also write your own code to automate tasks in VisualAge. We would a build script that would export all the code twice a day, build it, and email everyone if their was a problem! otherwise upload the new build to the test server.
Aha! So you built the code outside of VAJ, eh? Good idea, but that's not exactly how the tool is supposed to work, right;-)?
It made our lives a lot easier.
Yes, in some respects, and sometimes it made life harder for us. The workspace would get corrupted for no good reason, at random times. Everybody kept a clean backup of their workspace file around. Overriding standard packages was a pain in the neck (we wanted to use the Xerces XML parser. We succeeded in the end, but it took me several days of messing around with VAJ before it finally worked).
The Visual Composition option is almost useless. The code it generates is really inefficient and almost impossible to maintain. While the idea is nice, the technology simply is not mature enough yet. Most IDEs suffer from this problem by the way. The only one that produces (barely) acceptable code is JBuilder, and even that code needs some cleanup afterwards.
Another gripe: CLASSPATH. If you're used to working with an editor and the command line (or makefiles) you think that once you set up the CLASSPATH properly all should be well. Not so in VAJ. It has 2 different CLASSPATHs: one for compiling and one for running, and they're not always the same. So, every developer exclaimed at one point in time: "How can I get a ClassNotFound exception? The damn thing could find it when it compiled it!". While I see that it can be useful to run with different CLASSPATHs, it sure was a gotcha for all of us.
After all these complaints, I should say something nice about VA Java. It is tremendously powerful. On-the-fly compilation is nice (and sometimes a pain), code completion is nice, and the way it can suggest corrections (e.g., if you forget to import a package, you can correct that with a single click) is truly innovative and very useful. The editor is below par if you're used to EMACS, but I'm told there is a way to integrate it with VAJ. And here lies part of the problem. It is so powerful that is it kinda hard to figure out how to do something like that. The help system is no help here either (searches result in totally irrelevant hits). Bottom line is that you need a VAJ guru.
Summarizing, I have mixed emotions. Very powerful (lots of features I haven't even mentioned), but therefore a steep learning curve. Often people were spending more time futzing around with the tool than anything else. Some features simply don't work well. Sometimes I loved the tool, sometimes I wished I could just use an editor and type "javac..." at the command line.
Again, people forget that the Internet spans more than the USA. Any effort to fight this form of terrorism will have to be global to be effective. Given the Orwellian nature of these laws, it is highly unlikely that any worldwide consensus will be reached on this anytime soon.
From the Wired article:
Rep. Vernon Ehlers (R-Michigan) suggested additional punitive measures. "I think hackers should also be considered terrorists and sentences that hackers get should be in line with terrorist sentences," Ehlers said.
Besides from this being completely out of proportion, you're not gonna stop a suicidal terrorist by imposing stiffer sentences. Does he really think tougher sentences will scare off terrorists from hacking?
Slashdot Mirror
A theory about that statement I make is that there is an equal amount of matter as there is anti-matter.
Ah, but no, that's one of the great conundrums in cosmology.
Current theories are that after the Big Bang there were equal amounts of matter and anti-matter, but not quite. For some unknown reason, there was a very tiny fraction more matter than antimatter. The antimatter annihilated the matter, except for the the tiny fraction of matter. And that tiny fraction makes up the known universe...
If there were exactly the same amounts of matter and antimatter, they would annihilate given enough time.
So, it's very unlikely that there is antimatter "out there".
Ah, no, you're not the only one. It should be rather obvious. The whole point is that antimatter is only useful as energy storage. So, you would have to have a cheap energy source, a somewhat efficient way of storing the energy in antimatter, plus a safe and practical way of storing the antimatter (quite a challenge). Unless you could harvest hydrogen in outer space and convert it to anti-hydrogen....
Well, here's your response. And somebody please mod this up as Funny!
It's very costly to mathematically prove that a program has zero errors ...
Here I go in pedantic mode again. It's actually impossible to mathematically prove that a program is correct. It has been mathematically proven that a correctness proof does not exist (meta-proof...).
Notwithstanding all the research on formal correctness assurance methods, when you go to a low enough level (i.e. machine instructions), the methods all fail. As a friend of mine once said: "at least you can prove it's not your fault" , but that's about as far as it goes.
Having said that, NASA's methods are extremely thorough (specify, specify, specify, test, test, test, ad nauseam), and the Space Shuttle's software is probably by far the most reliable in the world.
It is also very unlikely that NASA will ever do anything with most of these research projects.
I think you're absolutely right, however, the one or two research projects that do lead to something useful might actually be very useful. To state the obvious, this is the very nature of scientific research. Look at drug companies: out of a thousand compounds they test, maybe one or two will lead to a marketable drug. However, the one or two might just be the cure for cancer or AIDS, or whatever. If you look at the history of scientific research, you'll find that most revolutionary things came from fundamental research, that never promised to result in anything useful in the beginning. A few examples: low temperature research (superconductors), research into the structure of the atom (nuclear energy, nuclear medicine, and -unfortunately- nuclear weapons), mathematical group theory (error-correcting codes), solid stae physics (transistor->microprocessor->computers->I nternet), etc.
Although I generally agree with you, consider this:
This type of research is very long-term, i.e., you and I will probably never reap the benefits. However, our great-grandchildren might be thankful. We would never have today's technology if our ancestors had not had the courage to dream of great things, and act on their dreams.
Nuclear efficiency is in between. While there is not complete conversion, there is some mass going to energy, unlike in chemical rockets.
Err, no, that is wrong. Chemical reactions transform mass into energy just as nuclear reactions do. It's just that chemical reactions transform a far smaller percentage of mass into energy. So, as you correctly point out, it's an efficiency thing. The reason is that chemical reactions work on the binding energy between electrons, whereas nuclear reactions act on the
atom's nucleus, where energies are magnitudes higher.
It's all rather confusing, since the number and type of particles are the same before and after the reactions, both for chemical and nuclear reactions. However, the assembly of particles have different masses before and after reactions. So where did the mass that was converted come from? Well, just as mass is equivalent to energy, so is energy equivalent to mass. The binding energy in atoms is mass, obeying E=mc^2. And that is the energy/mass that is freed during a reaction, be it a chemical or nuclear reaction.
Hope that didn't confuse things any further...
Side note: one of the more offbeat theories about the Tunguska explosion was that it was a chunk of antimatter, not an asteroid.
Offbeat indeed. Occam's razor: "the simplest explanation is usually the right one"
You don't need antimatter to explain the Tunguska explosion. Even a modest asteroid packs an enormous amount of (kinetic) energy, with the average speed of about 50 km/sec.
To quote The Pragmatic Programmer, by Andrew Hunt and David Thomas: "when you see hoofprints, think horses, not zebras"
The law of conservation of matter has been merged with the law of conservation of energy, and the two are now the law of conservation of matter-energy. All Einstein's fault. It's the famous E=mc^2 equation, that tells us that the conversion ratio between matter and energy equals c^2 [m^2/s^2]. That's a rather high number (~ 9*10^16 m^2/s^2), so we don't really notice the disappearing matter in real life. In other words, yes, matter is annihilated (destroyed), but we rarely notice. Note that this does not just apply to matter/anti-matter reactions, "ordinary" nuclear and chemical reactions obey the same law.
It has been demonstated in lab experiments that the opposite also holds. Given the right conditions and the right amount of energy, you can actually make particle/anti-particle pairs pop up out of nowhere!
Surprisingly enough, no, this is not a problem.
Let's make a few assumptions:
The distance to Mars would be 55*10^6 km = 55*10^9 m.
We use a 1 g accelleration all the way. That's the same as on earth. We turn the ship when we're halfway there and start braking with 1 g, so we can actually stop and do some sightseeing on Mars.
Now, assuming we start with a velocity of zero, the equation relating distance and accelleration is:
s(t) = 0.5*a*(t^2),
Where s = the distance in meters, t is time in seconds, and a is accelleration in m/s^2.
One g is approximately 10 m/s^2. s(t) is our halfway distance, or ~ 27.5*10^9 m. Substituting all that results in:
t^2 = 55*10^8, so t ~ 74000 seconds ~ 20.5 hours. That's for the trip halfway, so the total travel time would be around 41 hours = less than 2 days!
The top speed would be an impressive 740 km/s, which is high, but not nearly high enough to get in trouble with Einstein's relativity laws.
So, a few weeks doesn't seem that unreasonable. It's more the anti-matter thing that seems to be the problem.
Btw., let me know if I miscalculated anything....
That's fun, but you're overdoing it. You lose credibility that way. My method consists of your first two steps (i.e., just double it). I usually finish a bit below my estimate that way ("boy, this guy knows how to estimate"). Sometimes I finish a bit over the estimate, but that's generally accepted. My biggest miss was when I estimated three days, and it took only one. I could have goofed around for the remaining two days, but that's not very ethical. Besides, finishing two days ahead of schedule is far easier to sell to your manager than the opposite :-)
Yes. Unfortunately, this idea is not used very often. It is inspired by newspaper deadlines (where deadlines are actually deadlines). Same thing for the TV news.
As far as I know, the only software development area that enforces time boxing is the space business ("if we don't launch this probe by next year, we'll have to wait until the next launch window opens up in 2087"). In other areas, people know that deadlines are flexible, and actually expect release dates to slip.
Agreed. To add a few comments rather than create a new post:
Most projects do not have any algorithmic complexity at all! E.g. a lot of (Web) systems are no more than a GUI on top of a database. Any algorithmic problem (e.g. sorting) is usually already solved in some library or 3rd party tool.
Most developers are pretty good at estimating the time it takes to write a piece of code (as long as it is reasonably clear what the code is supposed to do). The problem is that managers usually don't like the estimate, and pressure the developer to come up with a lower estimate. I can't even count the number of times I heard "that answer is not good enough" (my usual response is to say: "well, at least it's true, so I think it's a pretty good answer").
Unfortunately, many developers do not have the courage to hold their ground and stand up to their manager. This problem is exacerbated by the fact that a slipping schedule is usually accepted, since it happens all the time!
Also, sometimes you simply cannot make a reasonable estimate, since there are too many uncertain factors. Just say "I don't know", it's a perfectly good answer, and a lot better than the answer that your manager wants to hear, but that is based on nothing.
By the way, a good manager will appreciate an honest answer.
Lastly, a lot of problems are caused by technology hype. A manager has read in Business Week that C# (or EJBs, or whatever) is the wave of the future, so that's the way to go. Never mind if it is relevant for the problem to be solved. Developers are even more to blame for this. In 1997 I worked on a brand new project that used Java, Swing (while still in beta), CORBA and an OODBMS. Talk about technology risk! Developers like this stuff
because it is cool, and it's good for their resume. Projects like this usually crash and burn because they lose sight of the fact that at the end of the day you have to make a profit, or else the company will be out of business some day, and you have to look for another job. The solution of course is to go into academic research (doesn't pay a lot) or join the research department of a company like IBM (only few of us are so lucky, though...).
And the copy-protection scheme is Reed-Soloman...
Um, no. Unless I'm terribly mistaken, a Reed-Solomon code is an error-correcting code, especially good at correcting burst errors (think scratches). If it is used for copy-protection, it's the first time I've heard of it.
If I remember correctly, the whole error-correction scheme belongs to Sony.
Really? I don't dare to claim that you are wrong about this, but I can remember (way back when) a Philips researcher visiting my (Dutch) university, explaining all the design decicions behind the choice for the (Reed-Solomon) coding. Could be that they collaborated with Sony on that, but my impression then was that is was all developed by Philips.
Yet the main inventor is Phillips.
I think this is correct. As I remember it, the main reason Philips involved Sony in the CD development in the first place, was that they wanted to get a foot in the door on the Japanese market, to prevent a repetition of the VCR mess (multiple standards). Might have been propaganda by the Dutch media, of course...
...they're a UK company primarily
Err...I don't think so. Granted, they're all over the world, but they're originally a Dutch company, still headquartered in the Netherlands, and as far as I know is their research lab (which gave us the CD, audio cassette, NiMH rechargeable batteries, electric razors with rotating blades and a whole lot more) also still in the Netherlands.
I'd mod you up as "Informative", but unfortunately I used up all my mod points last night. As a Dutchman living in the US, I share your frustration, I see the misspelling in print as well. Oh well, at least they have an astounding amount of Philips fluorescent lights in this country ;-)
Well, excuse my ignorance, but what's the point in having 24 bit 96 KHz? I'm assuming 24 bits applies to the samples, and 96 KHz is the sample frequency. So, that would result in much lower quantization noise, and the ability to reproduce frequencies up to 48 KHz (if Nyquist's law still applies). What speaker is going to reproduce this faithfully? Not to mention the frequency response of your ears? I'm not trolling, I really am curious: did you listen to 24 bit 96KHz audio, and did you really hear a difference with 'plain' CD quality?
Two fine fellows posting 14,000 messages on 100 message boards is a wee bit over the top, I think.
Hmmm....how about writing an editorial in a newspaper that has 14,000 subscribers?
Just being difficult....
You live in Washington State?
Let's face it, folks: there is no right to anonymity.
The Constitution isn't the final yardstick to measure everything against. You could argue that there is at least a moral right to anonymity (as opposed to whatever the Constitution mentions). Ironically enough, the Founding Fathers recognized the fact that they did not hold all wisdom for eternity, and included the concept of amending the Constitution, which has actually happened quite a few times...
Why is that? Are you planning to criticize Berman or G4? Or do you think they'll start prosecuting people who have the audacity to express their non-party-line opinions on their private websites? Couldn't happen in America, could it?
I wonder if this Cyclone makes programming "safer" by making it more difficult. What I mean by this is that some languages out there don't let you use pointers at all, or perform all sorts of checks on array bounds before each access. I like to call this "broken programming" simply because it isn't right in my opinion.
I disagree. Take for example Java, which does not have pointers. That hardly makes programming harder, it's easier if anything. An enormous amount of bugs are related to poor memory management. Most programmers make mistakes here. Array bound checks are pretty useful. Most compilers let you switch them off, so you can develop with array bound checks enabled, and disable them once you're convinced that everything is working right(...).
I like to compare pointers to a chain saw: a powerful tool in the hands of an expert, but most people should not even touch it...
A programmer should have all tools available to him, and should choose the best tool for the job when solving any given problem. Taking away tools doesn't make programming safer--it makes programming messier.
Seems to me that Cyclone is adding a tool rather than taking something away.
I thought this is what Lint is for.
Yes, lint is an excellent tool. Problem is that nobody uses it, unless forced by some project guideline. Worse, I have seen plenty of fools who disable all compiler warnings. Seems like Cyclone is building lint-like capabilities into the compiler, so you're forced to use it. Does not seem like a bad idea to me. My experience is that if you give programmers the opportunity to hose themselves, they will invariably do so.
I think that careful programming and use of a tool like Lint can make a better improvement than taking away some of the most powerful tools in programming just because some people don't know how to use them.
Unfortunately, most people don't know how to use them, or are unwilling to spend the extra effort. Careful programming requires discipline, something that most free spirits in software development are lacking.
Having said all this, I don't think Cyclone will cause a major revolution in programming. Most people are not waiting for Yet Another Language...
I don't know if I agree or not, but it's a valid point. It has been argued that any ET civilization we might contact would likely be far ahead of us technologically, exactly because of the short period that we have been in the technological age. Hostile or not, a civilization that's far ahead of us is likely to be dangerous.
Like all IDEs it got it's good points and it's bad point's.
Agreed.
Lots of people don't like the fact that it kinda hides the Java code from the programmer by only displaying one method at a time. I hated this feature when I first used it.
After a while, you'll either really get to like this feature or simply get used to it.
I'm afraid I still hate it. Fortunately, it offers a "Source View" option. This basically displays the code in a more traditional manner (i.e., all methods are displayed in the same window). Two problems with that: 1. It rearranges the order of the methods all the time. I like to have my main method at the bottom of the class, and the constructors at the top. Unfortunately, VA Java has its own ideas of what looks cool. 2. If you want to add a comment section between methods, it gets confused as to which method the comment section belongs. Sometimes it puts it in the right spot, sometimes in the wrong spot, and worst of all, sometimes it completely discards the comment section. So here I am, being a good boy and adding extensive comments, I hit Save and all my work is gone. Comment from the IBM guy on the project: "Don't use that feature".
One of the main reason I like Visual Age is because of its build in code repository. This repository is really usefully for team development (much easier/faster then cvs).
I can't comment on CVS, but VAJ's versioning/CM sure is a lot worse than ClearCase. The versioning is sort of OK. Every save operation creates a new (timestamped) version, so you can always go back (nice). Side effect is that the repository file becomes rather large pretty quickly (several hundreds of MBs). However, when doing explicit versioning, the version numbering is totally left to the developer, as long as the version does not already exist. You think version 1.2.1 is newer than version 1.1.6? Well, probably, but not always. Strange surprises can happen here.
The main problem is with defining a configuration (or "solution" in VAJ lingo). Every package version and possibly every class version needs to be hand-picked(ClearCase lets you define sophisticated selection rules. Once that is done, building a configuration is automatic). This may not seem to be a big deal, but my experience is that it became a maintenance nightmare quickly. And we only had half a dozen developers. We had one guy waste 2 weeks because he had been working on the wrong versions. The rest of the team spent more time futzing around with the CM system than with cutting code.
To IBM's credit, VAJ does offer 3rd party CM tool integrations. Unfortunately, the ClearCase integration turned out to be buggy and unreliable.
Merging code that more then one person worked on couldn't be simpler.
I must have missed something here. I found it to be cumbersome. Could be me, though (no sarcasm intended).
It's debugger is far ahead of anyone elses.
Agreed. Sometimes it got a little confused, but that's a minor complaint. Overall, the debugger is truly excellent.
You can also write your own code to automate tasks in VisualAge. We would a build script that would export all the code twice a day, build it, and email everyone if their was a problem! otherwise upload the new build to the test server.
Aha! So you built the code outside of VAJ, eh? Good idea, but that's not exactly how the tool is supposed to work, right
It made our lives a lot easier.
Yes, in some respects, and sometimes it made life harder for us. The workspace would get corrupted for no good reason, at random times. Everybody kept a clean backup of their workspace file around. Overriding standard packages was a pain in the neck (we wanted to use the Xerces XML parser. We succeeded in the end, but it took me several days of messing around with VAJ before it finally worked).
The Visual Composition option is almost useless. The code it generates is really inefficient and almost impossible to maintain. While the idea is nice, the technology simply is not mature enough yet. Most IDEs suffer from this problem by the way. The only one that produces (barely) acceptable code is JBuilder, and even that code needs some cleanup afterwards.
Another gripe: CLASSPATH. If you're used to working with an editor and the command line (or makefiles) you think that once you set up the CLASSPATH properly all should be well. Not so in VAJ. It has 2 different CLASSPATHs: one for compiling and one for running, and they're not always the same. So, every developer exclaimed at one point in time: "How can I get a ClassNotFound exception? The damn thing could find it when it compiled it!". While I see that it can be useful to run with different CLASSPATHs, it sure was a gotcha for all of us.
After all these complaints, I should say something nice about VA Java. It is tremendously powerful. On-the-fly compilation is nice (and sometimes a pain), code completion is nice, and the way it can suggest corrections (e.g., if you forget to import a package, you can correct that with a single click) is truly innovative and very useful. The editor is below par if you're used to EMACS, but I'm told there is a way to integrate it with VAJ. And here lies part of the problem. It is so powerful that is it kinda hard to figure out how to do something like that. The help system is no help here either (searches result in totally irrelevant hits). Bottom line is that you need a VAJ guru.
Summarizing, I have mixed emotions. Very powerful (lots of features I haven't even mentioned), but therefore a steep learning curve. Often people were spending more time futzing around with the tool than anything else. Some features simply don't work well. Sometimes I loved the tool, sometimes I wished I could just use an editor and type "javac..." at the command line.
Again, people forget that the Internet spans more than the USA. Any effort to fight this form of terrorism will have to be global to be effective. Given the Orwellian nature of these laws, it is highly unlikely that any worldwide consensus will be reached on this anytime soon.
From the Wired article:
Rep. Vernon Ehlers (R-Michigan) suggested additional punitive measures. "I think hackers should also be considered terrorists and sentences that hackers get should be in line with terrorist sentences," Ehlers said.
Besides from this being completely out of proportion, you're not gonna stop a suicidal terrorist by imposing stiffer sentences. Does he really think tougher sentences will scare off terrorists from hacking?