As an example of what I mean, check out the C++ coding guide for one of the biggest users of C++ - Google: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [googlecode.com]. You suggest "use standard libraries, exception handling, and make sure all your news have deletes", but Google engineers say don't use exceptions, don't use iostreams except for logging, and avoid a whole slew of C++ features like RTTI, multiple inheritance, automatically generated constructors / copy constructors / assignment operators, operator overloading, etc.
Some of these are a simple matter of the chosen application domain. Keep in mind that nearly everything Google does:
uses a web interface
uses a distributed back end.
needs to be highly scalable.
These mean that nearly all external communication needs to be via sockets or something similar. Although people have written code to make iostreams talk through sockets, the concepts involved are sufficiently different that it rarely works very well. Ergo, for a web-based communication, you need a different model from iostreams.
The combination of web-based and highly scalable also implies that most data being stored in the back-end shouldn't generally be in normal files either -- you're generally going to store the user's data in something like a database instead. For the few things (e.g. Google's index of the web) that really are shared across the entire application, they have their own file system and such, so you access them as they require -- which probably doesn't fit with iostreams very well either.
RTTI and multiple inheritance are like parachutes: most people should and will never use them. A few will use them once in a while, and a tiny proportion (who most people think are mildly insane) use them on a regular basis. Like a parachute, however, you should be glad it's there even if you never use it (directly) -- if you ever need it, you'll really need it, and then there's really no substitute.
At least some of their advice also stinks of simple elitism -- the people writing the standard making it clear they they know how to use this feature safely and well, but don't trust the peons who have to follow the standard to do the same. In fairness, that attitude is somewhat justified -- for an obvious example, just knowing how to program (even extremely well) does not imply knowing how to write exception-safe code. In fact, recent college graduates rarely know much about exception safety. Worse, even once you do know, it requires substantial discipline to really do it.
The same applies to quite a few things like compiler-generated copy constructors. If you design your classes well otherwise, they're not a problem at all -- but from what I've seen, roughly 99% of recent college graduations not only haven't been taught to design their classes well, but have been actively taught to design their classes poorly!
In short, most of the conclusion to be drawn from the Google coding guidelines comes down to two things:
Google codes primarily for a fairly specific domain
Most colleges do a lousy job of teaching programming
Probably never. The very fact that you mention Einstein makes that clear.
Newtonian physics does a good job of explaining and quantifying most of the physics we experience on an everyday basis. For example, we all experience gravity all the time, and Newtonian physics gives a detailed and accurate description of gravity as we normally experience it.
At least from most people's viewpoint, Einstein was the one who started from "everyday" physics we experience directly, and pushed it into the realm where it took real thought, then went beyond that into a realm most people can't really understand.
That means that later physicists work almost entirely in a realm that has little relationship to everyday life. No matter how great a contribution such a later physicist might make, almost nobody but another specialist can or will grasp what they're doing to a degree necessary to recognize the magnitude of their contribution. Thus the fact that you mention Einstein rather than Hawking.
If you want to prevent someone from patenting your creation after the fact, you release it wide and far without encumbrance. The fact that you have publicly released prior art prevents them from getting a patent, or overturns that patent should it pass through the patent office. Patents do not protect citizens from patents.
In theory, your argument should be completely correct. In practice, however, it's dead wrong. Most patent offices do at least some searching of prior art before granting a patent -- but their primary (often nearly only) source of prior art is prior patents and patent applications.
That being the case, applying for a patent with no intent of ever enforcing it really can be a useful way to help ensure against anybody else obtaining a patent on it.
Another nutty ruling.. if you willingly sign a contract that contained a non-complete clause, that's your issue with the company you should fight for.
Read the ruling. The situation is that California law specifically prohibits non-compete agreements in general, giving three specific exceptions under which they can be valid. The question, then, was whether this specific non-compete agreement fit any one of those exceptions. The court simply decided that the answer to that question was "No."
The only part of the ruling that could possibly be called "nutty" was the part where the supreme court reversed the appeals court. IMO, the dissenting opinion makes quite clear that this portion of the ruling truly was "nutty". The basic question in this part of the ruling was whether it was wrong to try to get an employee to sign an agreement that waived rights the law specifically said could not be waived. The majority basically decided that since the law said so, the employee could be expected to realize that this was not valid, and requiring him to sign the paper was, therefore, reasonable. I agree much more with the dissenting opinion: most people won't realize the clause is illegal, so it effectively deprives them of their legally mandated rights -- and that is wrong.
You are assuming that you are going to try every possible key, but there is no need. All you need to do is try every possible password that can be typed on a computer keyboard.
There's little essential difference between the two -- most systems allow you to enter nearly any random character from the keyboard. For example, under Windows, you can use [alt]0xxx to enter arbitrary characters (e.g: ÃÃ), or you can (for most programs) choose and paste them from the "character map" utility. In the end, you simply need to ensure you've entered enough entropy -- and, of course, the more predictable that data is, the more you have to enter to achieve enough entropy.
I tend to agree with what I think you're saying though: most people, most of the time, probably use passwords that are small and predictable enough that they're a lot easier to break than the algorithm with which they're typically used. Poor passwords, however, are a lot simpler for most people to fix than poor algorithms. The problem is that "simple" does not imply "easy" -- it's trivial to tell people to each important password should be unique and unpredictable. Without something like a smart-card to store passwords, however, it's a lot harder to get people to really do it in practice though...
I use snail mail. It's safer because it's sealed. Snail mail FTW.
Nice try, but generally trivial to break. For starters, there's the always popular method of steaming envelopes open.
Of course, that's pretty easy to prevent -- for example, people who cared have used wax seals for centuries.
That's still a long ways from secure though. For example, one trick (also known for a long time) uses a thin metal rod, split along its length. You insert the rod under the end of the envelope flap, where there's no seal. You catch the letter where it's folded, with one side of the fold on each side of the split, then twist the rod to roll the letter up, and remove it back out the end. When you're finished reading it, you reverse the process to re-insert the letter into the envelope.
It's no accident that, historically, most countries' code-breaking agencies have been attached to their postal services...
If you want encryption guaranteed against major governments you have to go with a one time pad. Even then you've got to worry about Van Eck Phreaking or FPGA eavesdropping.
Actually, the one-time pad is almost never a good choice. In particular, to be completely effective you must ensure that your pad is entirely random. The recent problem in Debian, like a much older one in Netscape 4 (or thereabouts) were both with generating random numbers, not with the encryption algorithms themselves.
The bottom line is that the one-time pad cures a difficult problem, but substitutes one that's generally even more difficult in its place. For the average person, the chances of security from something like AES or RSA are much better than from a one time pad.
Re:no encryption that YOU didn't write is safe
on
Is Hushmail Still Safe?
·
· Score: 3, Informative
The NSA (among others) does actively hinder research on cryptography outside the government, and those efforts are fairly well known. For example, the although the limits on things like key size have been raised, there are still controls on the export of some types of cryptography. They have attempted (at times) to apply these to publication that should clearly have been immune to it, such as a researcher publishing information about an algorithm, rather than attempting to export a working system.
It's also NOT necessarily true that for every brilliant person in the government, there's another who works elsewhere, at least specifically on cryptography. In particular, the NSA is one the largest employers of mathematicians on earth. Most other employers who hire mathematicians have other jobs for them to do, so most of their time is occupied with other problems. By contrast, the NSA can (apparently) afford to hire quite a few who are allowed to concentrate entirely on cryptology.
Given the secrecy of the NSA in general, it's essentially impossible to come up with numbers that are either exact or concrete, but it certainly seems possible and reasonable that government agencies (in general) could have considerably more time and effort to devote to this subject than the entire rest of the world.
My feeling, however, is that the gap has been narrowing for quite a while now. From the design of DES, it appears that the NSA was aware of differential cryptanalysis (but not linear cryptanalysis) at that time; it became publicly known quite a bit later. As for AES, however, the rest of the world has caught up to the point that AES can be used on DOD Secret data, and the variants with 192- and 256-bit keys are cartified for DOD Top Secret data.
I believe that would likely be DES you're referring to, not 3DES.
You're probably right, but technically it's still wrong. To clarify: DES stands for the "Data Encryption Standard". It was originally published in FIPS 161. That was later replaced by FIPS 161-1 and FIPS 161-2, both of which were essentially unchanged.
That, however, was then replaced by FIPS 161-3 -- which has a major change. In particular, as of FIPS 161-3, the standard requires three applications of the algorithm (EDE, in case you care) -- i.e. what most of us think of as triple-DES or 3DES.
Re:no encryption that YOU didn't write is safe
on
Is Hushmail Still Safe?
·
· Score: 2, Insightful
Truecrypt is freeware (open source) and is secure. In fact, it's more secure than any commercial offering I know of, due to its plausible deniability features. The source is there, it has been examined by experts and you can take a look yourself. Encryption options include both AES and Twofish, both known to be secure.
They're not"known to be secure". They're simply not known to be insecure.
One of the basic problems in cryptography is that security is essentially impossible to prove -- about the best you can hope for is to prove that if X is true, then Y is also true, and Y implies that this algorithm is difficult to attack in some specific way.
To give a concrete example, RSA encryption is based (as most people already know) on publishing a key that's (basically) the product of a couple of large prime numbers (which are not published separately). It's pretty easy to say that RSA is secure against an attack based on factoring if and only if factoring is sufficiently difficult. It's possible, however, that a much easier/faster algorithm for factoring could exist -- nobody knows for sure.
There's also the possibility of attacking RSA encryption in other ways. Even though factoring the public key is an obvious route, there may be entirely unrelated attacks. For example, Seifert invented an attack on RSA-based digital signatures that does not involve factoring the public key at all (though the attack does have some requirements that aren't necessarily easy to meet).
The same general idea is true with most symmetric encryption algorithms, but the proofs involved are much more difficult to reduce to something easy to explain in a short post -- they mostly involve group theory that even people who major in things like math or CS never study (at least in any detail).
In the case of AES, there is a type of algebraic attack (XSL) that's never been proved to work, but shows reasonable promise. In particular, it has been shown to work against what are basically reduced versions of AES, which is usually a strong clue that an attack against the full cipher may work as well (though making it work isn't necessarily easy, of course).
In theory, with a few billion dollars you could build a machine capable of cracking AES in months.
I'm not at all sure that's true. For it to be true, there would have to be an attack that was substantially faster than simply exhausting the key space. If somebody can make something like XSL work, breakage might even be a lot easier than that. An attack based on trying every possible key, however, is completely out of the question. There's not enough silicon in the solar system to build enough cipher engines to do the job before the sun has become a red dwarf. In fact, it's open to question whether there's enough matter/energy in the universe to do the job before the universe is in heat death.
...except that it's integrated into a completely unusable ide - eclipse.
There, fixed that for you.
Seriously, looking at the website, it looks more like what I'd expect from a project still looking for funding, not something that's supposed to be close to completion. In particular, it talks about objectives and such, but doesn't seem to have any code available for download/testing. By my count you've used up about 18 of the 30 months for which you were funded, but if there's anything to show for that work, it's not apparent from the web site.
I'm probably going to be shouted down but in my 30 years of coding, I *rarely* reused code.
Donald Knuth recently said: "I also must confess to a strong bias against the fashion for reusable code."
Personally, I think a lot depends on the sorts of things you do, and (probably more importantly) the way you tend to think. A few decades ago (or so) when I started college, Pascal was the cool new thing, and top-down development was going to save the world. At least IMO, top-down development has some very good points -- but code reuse isn't one of them.
OTOH, some people tend to work and think primarily bottom up. For them, work on a particular project basically consists of building a good library for that type of work, and once they have a good library, that particular project is little more than building a user interface to give access to those components.
One big problem is that code reuse has been pushed as a good idea for long enough not that a lot of people who simply don't have the mindset to produce reusable code still feel that they should do so, and feel guilty if they don't. IMO, this is silly -- there's a lot of room for both kinds of development, and IME, successful projects rarely stick to one direction or the other -- rather, there's a tendency towards some people working bottom up, and others top-down, and the project as a whole is more or less a "meet in the middle" approach.
Of course, getting this to work requires a fair amount of care -- in particular, you need to ensure against a major "fault line" where the top and bottom sides meet. Unfortunately, I don't have an easy prescription for preventing that -- if I did, I'd probably be the author of a famous book instead of some unknown guy writing on slashdot...:-)
I wonder how big the market is for people that really NEED that much resolution?
Tiny. Then again, if it was very large, things could get interesting in hurry. There's virtually no such thing as a medium format camera being produced in huge quantities (e.g. like SLRs in the APS-C and 35mm size range are).
And I wonder how many people's computers will absolutely CRY when trying to open a 50mpix tiff. My 6mpix jpegs are 2.5-3.5mb. (the tiffs are 15-16mb iirc) at 50mpix, 29mb would make for a terribly large and unwieldy jpeg.
I fairly routinely put together panoramas with 15-20 shots from a 12 MP camera, and my computer has no major problem with them at all. Oh, and I certainly do not work from JPEG as a rule -- I normally start from raw, convert to 16-bit TIFF, and splice those together. When these are put together, the result is typically in the 150-200 megapixel range (in case you're wondering why it's lower than multiplying the resolution by the number of images, you need some overlap to match the images together).
Unlike a DSLR which has to expose the image sensor a slit at a time at higher shutter speeds, this means that the entire frame can be exposed simultaneously, down to 1/8000 sec.
This is the first time I've heard anybody claim a leaf shutter could to anywhere close to 1/8000 of a second. I can't find any indication that Compur or Copal has ever heard of such a thing either (most leaf shutters are manufactured by one of the two). OTOH, it's true that the entire frame can be and is exposed simultaneously down to its top speed of 1/500th of a second (and for the same reason, you get X sync at all speeds as well).
For comparison, a 35mm film frame (24x36mm, iirc) carries about 15 Megapixels (there is wide consensus on this).
Wide, perhaps, but not very deep, so to speak. Anybody who believes the limit on film is around 15 megapixels has essentially no clue of what they're talking about.
A really good 35 mm lens, with the camera mounted on a tripod, carefully focused, and stopped down to maximum sharpness (typically around 2-3 stops from wide open), can resolve around 100-110 lines/mm. Since the film plane is 24x36, that works out to 2400x3600 up to 2640x3960 lines. Keep in mind, however, that this is lines, not pixels. It takes two adjacent pixels to capture a single line. IOW, you're looking at around 35-40 megapixels.
It is true that resolution tends to drop towards the corners so the real overall resolution is likely to be (slightly) lower, and even the best zooms aren't very close to that -- we're talking about a fixed focal length lens. Of course to record that you're also looking at a slow, fine-grained film like Tech Pan 2415 for B&W or Kodachrome 25, Velvia or Provia for color.
OTOH, 15 megapixels is probably a reasonable number if you're comparing to a more typical shot that's hand held, autofocused and only at the optimum f/stop if that's what the camera's programmed auto-exposure happened to choose.
Is there any radioactive material that is potent enough for a dirty bomb? Wouldn't blowing the material up just spread it out so that it's doesn't emit enough rem to do damage?
Yes and no. For this purpose, the fact that uranium is radioactive is mostly incidental. Purified uranium is (approximately).7% Uranium-235 (radioactive) and 99.3% Uranium-238 (stable) -- but this is also irrelevant. Uranium, radioactive or otherwise, is poisonous, and breathing uranium dust is one of the more hazardous methods of ingestion. Most of the other commonly known radioactive materials (e.g. plutonium) are poisonous as well. This is the principle behind a dirty bomb -- to use the material as a poison, with its radioactivity mostly incidental.
That said, the real danger from a dirty bomb using yellowcake appears to be fairly minimal. First of all, yellowcake isn't really pure uranium. Rather, it's compounds relatively high in uranium, such as uranyl hydroxide hydrate, uranyl sulfate hydrate, sodium para-uranate, and uranyl peroxide hydrate. To produce anything very poisonous, you'd have to purify the uranium.
Then you're left with a few more problems, such as the fact that purified uranium is a soft, dense metal so that:
It's hard to get it to disperse evenly over a wide area
It tends to precipitate out of the air fairly quickly.
There's also the fact that while uranium is poisonous:
Quite a few other things (e.g. tetanus toxin and nerve agents) are far more poisonous
Uranium is a fairly slow-acting poison, mostly causing cancer.
All in all, the real threat from uranium in a "dirty bomb" is pretty minimal. For this purpose, lead would be about as effective, and a whole lot cheaper and easier to get.
But in fact the Google search engine, which is one of the larger "industrial-grade, internet-grade" systems I know of, is written entirely in C++. A language which is much the same as it was 10-15 years ago. Thus the central point of his argument seems flawed to me.
Not to mention Sabre and the VISA credit card processing system -- both use TPF, which is a lot older than Erlang. Meanwhile, many libraries have used the Tandem/Compaq/HP Non-stop system for years -- in fact, I'm pretty sure some have been up without a single interruption since before Erlang was invented. IBM has also had CICS for decades as well; IIRC, it's used by quite a few banks and hotel reservation systems. Likewise, substantial parts of the updates to the Air Traffic Control system currently in progress are being written in various older languages (more in Ada than any other, but it's certainly not the only one).
Now, don't get me wrong: none of these is a panacea for scalable programming. Nonetheless, the people who think they can create highly scalable systems using technology that's a lot more than 10 or 15 years old have some pretty good support. In fact, I can't think of a single really large scale system developed using only technology newer than that.
From a viewpoint of programming languages, there have been quite a few with support for various forms of parallelism over the years. Some (e.g. Concurrent Pascal) were oriented primarily toward tightly coupled processing. Others (e.g. Occam) were oriented primarily toward loosely coupled parallelism.
IMO, you just about need at least some degree of both. You can't take anywhere close to full advantage of a tightly coupled machine using only a loosely-coupled programming model. Likewise, if you want to scale to lots of separate machines, you just about need a more explicitly loosely coupled programming model.
If, however, you use a loosely coupled model even when it's not really appropriate, you may end up needing scalability, even when you otherwise wouldn't -- i.e. your code will be enough slower that it requires multiple machines, even when code using a more appropriate model wouldn't have required it.
I cannot stand people saying that I, or another person, need to "think about what he/she wants to do." How the heck am I supposed to know the answer to that question, if I have never done anything other than high school type jobs?
Note that said "what you want to do", not "what kind of job you want to do."
The fact is that to an extent you're right: first of all, despite "take your child to work" days, and such, most recent graduates (high school or college) have no clue of what a real job is like. Furthermore, I doubt it's really possible for them to have a really good idea -- you can't have a good idea of what it's like to have the same job for 20 years when you haven't been alive for 20 years, and things like school have changed quite a bit during that time, you can't remember the first few years of your life well at all, etc.
It's also true that if what you really enjoy is something like "hanging out at the beach", it's pretty hard to come up with a paying job doing anything very similar. At the same time, I think most teenagers do enjoy doing at least a few things that could reasonably translate into jobs.
I'd also note that the days of most people getting a job straight out of school, and then staying there until they retire are mostly a bit of history. I wouldn't worry a lot about the fact that you're not sure you're picking out the perfect job right off the bat -- chances are you'll move along to something else before a terribly long time anyway (maybe voluntarily, maybe not).
As such, the first job (or two) is mostly a matter of getting into the work place enough to get a lot better idea of the kinds of things you're good at and enjoy. Mostly before you get that first job you're hoping to find something close enough that you'll at least end up around somebody else who does things you might fit well with.
For those who are uncertain about things, my other bit of advice is to try to find a job at a relatively new, small company. A large corporation will usually have fairly specific job descriptions, and expect you to follow them quite closely. At a small company with relatively little organization, you can often do a lot of what you want as long as what you're doing is (or at least should be) useful. It's often pretty easy to try your hand at a fair number of different kinds of things, and (in a lot of cases) more or less create a niche for yourself doing the ones you're best at/enjoy the most.
Testing
Project Management
Product Support
Software Sales
Systems Administration
Programming is just one part of computer science; there are needs for all of these other areas as well.
Computer science has to do with research into computing, algorithms, etc. Programming, for the most part, is related to software engineering (though some programming also involves computer science). Most of the other jobs you mentioned have nothing to do with either one though.
The simple fact that a job is involved, to some degree or other, with computers, does not mean it has anything to do with computer science. In fact, more often than not, computer science is done with a pencil and paper. Software engineering is typically done with a computer, but primarily to run a text editor or (possibly) something like a UML editor.
Let me give one small example: from a viewpoint of computer science, graphics cards really only come in two varieties: those that you can program, and those that you can ignore. From a viewpoint of software engineering, there's more difference between cards, but it's expressed primarily in terms of the shader model the card implements. If you care much about things like how fast of RAM it has, chances are that neither computer science nor software engineering has much to do with that interest (which isn't to say that a computer scientist can't also enjoy playing a game now and again -- just that he knows the difference between the two).
The OP should really sit back and think about what he wants to do. The simple fact that he hasn't done much, or been taught much about, programming shouldn't be a major handicap if he honestly has a desire and aptitude for doing so.
It's a bit belated, of course, but if he doesn't want to program, he should sit back and think about 1) what he's good at, and 2) what he enjoys. He should then try to come up with jobs that are at least somewhere close to the intersection between the two.
Until or unless he does that, he's pretty much setting himself up for misery, failure, or most likely both. Most people have a hard time enjoying being bad at something for very long, and most people have a hard time caring enough to do things well if they don't enjoy it to at least some degree.
Of course you can always static-link to your libs, but how is that different from just shipping the JDK along?
It's drastically different, and if you'd read the previous posts in the thread, this would be obvious. With statically linked libraries, the user can have one application that requires one specific version of the library running alongside another application that requires a different specific version of a library, and never even know there was potential for a conflict.
Shipping the JDK with a Java application isn't like that at all. Yes, if the prescribed version of the JDK is installed with my application, it ensures that my application runs (assuming I've done my job even halfway reasonably, of course). Installing that JDK, however, may break some of their other Java applications -- and the only way to fix them is to re-install some other version of the JDK, and in doing so, breaking mine.
There is also a substantial difference in practicality: static linking adds some to the size of the program, but not anywhere close to the same as the size of the JDK. Installation isn't affected either -- static linking doesn't mean that the installation has to be carried out as root or anything like that -- whereas, the JDK normally should carry precisely such requirements, due (if nothing else) to exactly the problems outlined above.
Of course, with something like VMWare, you can get around even the degree to which Java is broken -- all you have to do is create a separate virtual machine in which to run a separate copy of the OS, on which to run each required Java Virtual Machine. In a decent world such a suggestion could only ever be a joke, and in poor taste at that. In the Java world, it's neither a joke nor even unusual.
So now I'm always wary about using Java applications, since they can easily get tied to a specific JRE and if that JRE has security flaws, you're SOL.
Same can be said of ANY language that evolves.
Not so. It's true of a language that makes the end user provide/install a large part of the environment in which the program runs. Technically, this isn't a characteristic of the language per se, but of the implementation. Nonetheless, it's not the sort of problem that arises for those who use languages like Fortran, C, C++, Ada, etc.
During development a similar problem can arise -- I can write code that requires a specific version of a specific compiler (or library). Somebody else can write code that requires a different specific compiler or library -- but unlike the situation with Java and such, this does not affect the end user.
Of course, even with a language like this, a programmer can use things like.so's or DLLs (as the case may be) that can lead to problems -- as I said, this is a characteristic of the implementation, not the language. Nonetheless, it's much easier to avoid with something C, C++ or Ada than with something like Java or Python.
The long and short of it is that Java was proven to be more than fast enough, with the average case easily keeping pace or beating C++ code.
More accurately, Java is usually more than fast enough, even though it's nearly never as fast as equivalent C++. When you get down to it, performance rarely matters much.
Java is not faster then C++ and it never will be. You can't fundamentally add the overhead of a byte code interpreter and somehome [sic] come out ahead.
Java doesn't necessarily involve a byte-code interpreter. JVMs have supplied Just In Time compilation for years now.
That's not a panacea though: optimization is generally a difficult task, and good optimization can be quite difficult indeed -- many (perhaps most) NP-complete problems are basically ones of optimization. While optimizing code isn't necessarily identical to a traveling salesman problem (etc.), there is quite a bit in common.
The result of that is that the really difficult optimizations are harder to justify in a JIT compiler. In a traditional compiled language, you compile a small number of times, and run many times. In a JIT environment, you compile far more often, so you can't amortize that cost over nearly as many executions.
What Java does and does very well is save programers [sic] from themselves.
I'm not convinced of this either -- Java adds garbage collection, which many people think will save the programmers from themselves. My experience indicates rather the opposite -- garbage collection makes very little difference to memory management, and lack of deterministic finalization makes most other resources considerably more difficult to manage.
The garbage collector in Java is very good. It was implemented by very good coders who had a very specific interest that they could focus on.
There is no one garbage collector in Java -- there's a garbage collector in each individual JVM. Some of them are better than others, and some are optimized for different loads than others. Languages that use manual memory management are similar: each implementation has its own, with its own characteristics.
For that matter, quite a few people use garbage collectors with C and C++. These garbage collectors are generally implemented by extremely good coders as well. C and C++ place a few obstacles in their way, so it's a bit more difficult to implement them, but they work reasonably well nonetheless.
In the end, however, I think the effect of garbage collection on speed of either execution or development seems to be quite exaggerated. In a few circumstances, it's really helpful. In others it's really harmful. Most of the time, it makes very little difference at all.
Just how many bad numbers do you need to see?????? Home values take the largest dump in 20 years. Oil hits all time highes [sic] everyother [sic] day. The dollar is weaker than ever in my life time (over 40). Food prices are on a huge increase.
All but one of those are really just symptoms of one number: the money supply. Look at the price of oil in terms of ounces of gold. Note that the bottom line of this graph is virtually dead flat.
Of those numbers, the only one that isn't an effect of money supply increases is the price of housing in the US -- it's the cause rather than the effect.
Slashdot Mirror
Some of these are a simple matter of the chosen application domain. Keep in mind that nearly everything Google does:
These mean that nearly all external communication needs to be via sockets or something similar. Although people have written code to make iostreams talk through sockets, the concepts involved are sufficiently different that it rarely works very well. Ergo, for a web-based communication, you need a different model from iostreams.
The combination of web-based and highly scalable also implies that most data being stored in the back-end shouldn't generally be in normal files either -- you're generally going to store the user's data in something like a database instead. For the few things (e.g. Google's index of the web) that really are shared across the entire application, they have their own file system and such, so you access them as they require -- which probably doesn't fit with iostreams very well either.
RTTI and multiple inheritance are like parachutes: most people should and will never use them. A few will use them once in a while, and a tiny proportion (who most people think are mildly insane) use them on a regular basis. Like a parachute, however, you should be glad it's there even if you never use it (directly) -- if you ever need it, you'll really need it, and then there's really no substitute.
At least some of their advice also stinks of simple elitism -- the people writing the standard making it clear they they know how to use this feature safely and well, but don't trust the peons who have to follow the standard to do the same. In fairness, that attitude is somewhat justified -- for an obvious example, just knowing how to program (even extremely well) does not imply knowing how to write exception-safe code. In fact, recent college graduates rarely know much about exception safety. Worse, even once you do know, it requires substantial discipline to really do it.
The same applies to quite a few things like compiler-generated copy constructors. If you design your classes well otherwise, they're not a problem at all -- but from what I've seen, roughly 99% of recent college graduations not only haven't been taught to design their classes well, but have been actively taught to design their classes poorly!
In short, most of the conclusion to be drawn from the Google coding guidelines comes down to two things:
Probably never. The very fact that you mention Einstein makes that clear.
Newtonian physics does a good job of explaining and quantifying most of the physics we experience on an everyday basis. For example, we all experience gravity all the time, and Newtonian physics gives a detailed and accurate description of gravity as we normally experience it.
At least from most people's viewpoint, Einstein was the one who started from "everyday" physics we experience directly, and pushed it into the realm where it took real thought, then went beyond that into a realm most people can't really understand.
That means that later physicists work almost entirely in a realm that has little relationship to everyday life. No matter how great a contribution such a later physicist might make, almost nobody but another specialist can or will grasp what they're doing to a degree necessary to recognize the magnitude of their contribution. Thus the fact that you mention Einstein rather than Hawking.
In theory, your argument should be completely correct. In practice, however, it's dead wrong. Most patent offices do at least some searching of prior art before granting a patent -- but their primary (often nearly only) source of prior art is prior patents and patent applications.
That being the case, applying for a patent with no intent of ever enforcing it really can be a useful way to help ensure against anybody else obtaining a patent on it.
Read the ruling. The situation is that California law specifically prohibits non-compete agreements in general, giving three specific exceptions under which they can be valid. The question, then, was whether this specific non-compete agreement fit any one of those exceptions. The court simply decided that the answer to that question was "No."
The only part of the ruling that could possibly be called "nutty" was the part where the supreme court reversed the appeals court. IMO, the dissenting opinion makes quite clear that this portion of the ruling truly was "nutty". The basic question in this part of the ruling was whether it was wrong to try to get an employee to sign an agreement that waived rights the law specifically said could not be waived. The majority basically decided that since the law said so, the employee could be expected to realize that this was not valid, and requiring him to sign the paper was, therefore, reasonable. I agree much more with the dissenting opinion: most people won't realize the clause is illegal, so it effectively deprives them of their legally mandated rights -- and that is wrong.
There's little essential difference between the two -- most systems allow you to enter nearly any random character from the keyboard. For example, under Windows, you can use [alt]0xxx to enter arbitrary characters (e.g: ÃÃ), or you can (for most programs) choose and paste them from the "character map" utility. In the end, you simply need to ensure you've entered enough entropy -- and, of course, the more predictable that data is, the more you have to enter to achieve enough entropy.
I tend to agree with what I think you're saying though: most people, most of the time, probably use passwords that are small and predictable enough that they're a lot easier to break than the algorithm with which they're typically used. Poor passwords, however, are a lot simpler for most people to fix than poor algorithms. The problem is that "simple" does not imply "easy" -- it's trivial to tell people to each important password should be unique and unpredictable. Without something like a smart-card to store passwords, however, it's a lot harder to get people to really do it in practice though...
Nice try, but generally trivial to break. For starters, there's the always popular method of steaming envelopes open.
Of course, that's pretty easy to prevent -- for example, people who cared have used wax seals for centuries.
That's still a long ways from secure though. For example, one trick (also known for a long time) uses a thin metal rod, split along its length. You insert the rod under the end of the envelope flap, where there's no seal. You catch the letter where it's folded, with one side of the fold on each side of the split, then twist the rod to roll the letter up, and remove it back out the end. When you're finished reading it, you reverse the process to re-insert the letter into the envelope.
It's no accident that, historically, most countries' code-breaking agencies have been attached to their postal services...
Actually, the one-time pad is almost never a good choice. In particular, to be completely effective you must ensure that your pad is entirely random. The recent problem in Debian, like a much older one in Netscape 4 (or thereabouts) were both with generating random numbers, not with the encryption algorithms themselves.
The bottom line is that the one-time pad cures a difficult problem, but substitutes one that's generally even more difficult in its place. For the average person, the chances of security from something like AES or RSA are much better than from a one time pad.
It's also NOT necessarily true that for every brilliant person in the government, there's another who works elsewhere, at least specifically on cryptography. In particular, the NSA is one the largest employers of mathematicians on earth. Most other employers who hire mathematicians have other jobs for them to do, so most of their time is occupied with other problems. By contrast, the NSA can (apparently) afford to hire quite a few who are allowed to concentrate entirely on cryptology.
Given the secrecy of the NSA in general, it's essentially impossible to come up with numbers that are either exact or concrete, but it certainly seems possible and reasonable that government agencies (in general) could have considerably more time and effort to devote to this subject than the entire rest of the world.
My feeling, however, is that the gap has been narrowing for quite a while now. From the design of DES, it appears that the NSA was aware of differential cryptanalysis (but not linear cryptanalysis) at that time; it became publicly known quite a bit later. As for AES, however, the rest of the world has caught up to the point that AES can be used on DOD Secret data, and the variants with 192- and 256-bit keys are cartified for DOD Top Secret data.
You're probably right, but technically it's still wrong. To clarify: DES stands for the "Data Encryption Standard". It was originally published in FIPS 161. That was later replaced by FIPS 161-1 and FIPS 161-2, both of which were essentially unchanged.
That, however, was then replaced by FIPS 161-3 -- which has a major change. In particular, as of FIPS 161-3, the standard requires three applications of the algorithm (EDE, in case you care) -- i.e. what most of us think of as triple-DES or 3DES.
They're not"known to be secure". They're simply not known to be insecure.
One of the basic problems in cryptography is that security is essentially impossible to prove -- about the best you can hope for is to prove that if X is true, then Y is also true, and Y implies that this algorithm is difficult to attack in some specific way.
To give a concrete example, RSA encryption is based (as most people already know) on publishing a key that's (basically) the product of a couple of large prime numbers (which are not published separately). It's pretty easy to say that RSA is secure against an attack based on factoring if and only if factoring is sufficiently difficult. It's possible, however, that a much easier/faster algorithm for factoring could exist -- nobody knows for sure.
There's also the possibility of attacking RSA encryption in other ways. Even though factoring the public key is an obvious route, there may be entirely unrelated attacks. For example, Seifert invented an attack on RSA-based digital signatures that does not involve factoring the public key at all (though the attack does have some requirements that aren't necessarily easy to meet).
The same general idea is true with most symmetric encryption algorithms, but the proofs involved are much more difficult to reduce to something easy to explain in a short post -- they mostly involve group theory that even people who major in things like math or CS never study (at least in any detail).
In the case of AES, there is a type of algebraic attack (XSL) that's never been proved to work, but shows reasonable promise. In particular, it has been shown to work against what are basically reduced versions of AES, which is usually a strong clue that an attack against the full cipher may work as well (though making it work isn't necessarily easy, of course).
I'm not at all sure that's true. For it to be true, there would have to be an attack that was substantially faster than simply exhausting the key space. If somebody can make something like XSL work, breakage might even be a lot easier than that. An attack based on trying every possible key, however, is completely out of the question. There's not enough silicon in the solar system to build enough cipher engines to do the job before the sun has become a red dwarf. In fact, it's open to question whether there's enough matter/energy in the universe to do the job before the universe is in heat death.
There, fixed that for you.
Seriously, looking at the website, it looks more like what I'd expect from a project still looking for funding, not something that's supposed to be close to completion. In particular, it talks about objectives and such, but doesn't seem to have any code available for download/testing. By my count you've used up about 18 of the 30 months for which you were funded, but if there's anything to show for that work, it's not apparent from the web site.
Donald Knuth recently said: "I also must confess to a strong bias against the fashion for reusable code."
Personally, I think a lot depends on the sorts of things you do, and (probably more importantly) the way you tend to think. A few decades ago (or so) when I started college, Pascal was the cool new thing, and top-down development was going to save the world. At least IMO, top-down development has some very good points -- but code reuse isn't one of them.
OTOH, some people tend to work and think primarily bottom up. For them, work on a particular project basically consists of building a good library for that type of work, and once they have a good library, that particular project is little more than building a user interface to give access to those components.
One big problem is that code reuse has been pushed as a good idea for long enough not that a lot of people who simply don't have the mindset to produce reusable code still feel that they should do so, and feel guilty if they don't. IMO, this is silly -- there's a lot of room for both kinds of development, and IME, successful projects rarely stick to one direction or the other -- rather, there's a tendency towards some people working bottom up, and others top-down, and the project as a whole is more or less a "meet in the middle" approach.
Of course, getting this to work requires a fair amount of care -- in particular, you need to ensure against a major "fault line" where the top and bottom sides meet. Unfortunately, I don't have an easy prescription for preventing that -- if I did, I'd probably be the author of a famous book instead of some unknown guy writing on slashdot... :-)
Tiny. Then again, if it was very large, things could get interesting in hurry. There's virtually no such thing as a medium format camera being produced in huge quantities (e.g. like SLRs in the APS-C and 35mm size range are).
I fairly routinely put together panoramas with 15-20 shots from a 12 MP camera, and my computer has no major problem with them at all. Oh, and I certainly do not work from JPEG as a rule -- I normally start from raw, convert to 16-bit TIFF, and splice those together. When these are put together, the result is typically in the 150-200 megapixel range (in case you're wondering why it's lower than multiplying the resolution by the number of images, you need some overlap to match the images together).
This is the first time I've heard anybody claim a leaf shutter could to anywhere close to 1/8000 of a second. I can't find any indication that Compur or Copal has ever heard of such a thing either (most leaf shutters are manufactured by one of the two). OTOH, it's true that the entire frame can be and is exposed simultaneously down to its top speed of 1/500th of a second (and for the same reason, you get X sync at all speeds as well).
Wide, perhaps, but not very deep, so to speak. Anybody who believes the limit on film is around 15 megapixels has essentially no clue of what they're talking about.
A really good 35 mm lens, with the camera mounted on a tripod, carefully focused, and stopped down to maximum sharpness (typically around 2-3 stops from wide open), can resolve around 100-110 lines/mm. Since the film plane is 24x36, that works out to 2400x3600 up to 2640x3960 lines. Keep in mind, however, that this is lines, not pixels. It takes two adjacent pixels to capture a single line. IOW, you're looking at around 35-40 megapixels.
It is true that resolution tends to drop towards the corners so the real overall resolution is likely to be (slightly) lower, and even the best zooms aren't very close to that -- we're talking about a fixed focal length lens. Of course to record that you're also looking at a slow, fine-grained film like Tech Pan 2415 for B&W or Kodachrome 25, Velvia or Provia for color.
OTOH, 15 megapixels is probably a reasonable number if you're comparing to a more typical shot that's hand held, autofocused and only at the optimum f/stop if that's what the camera's programmed auto-exposure happened to choose.
Yes and no. For this purpose, the fact that uranium is radioactive is mostly incidental. Purified uranium is (approximately) .7% Uranium-235 (radioactive) and 99.3% Uranium-238 (stable) -- but this is also irrelevant. Uranium, radioactive or otherwise, is poisonous, and breathing uranium dust is one of the more hazardous methods of ingestion. Most of the other commonly known radioactive materials (e.g. plutonium) are poisonous as well. This is the principle behind a dirty bomb -- to use the material as a poison, with its radioactivity mostly incidental.
That said, the real danger from a dirty bomb using yellowcake appears to be fairly minimal. First of all, yellowcake isn't really pure uranium. Rather, it's compounds relatively high in uranium, such as uranyl hydroxide hydrate, uranyl sulfate hydrate, sodium para-uranate, and uranyl peroxide hydrate. To produce anything very poisonous, you'd have to purify the uranium.
Then you're left with a few more problems, such as the fact that purified uranium is a soft, dense metal so that:
There's also the fact that while uranium is poisonous:
All in all, the real threat from uranium in a "dirty bomb" is pretty minimal. For this purpose, lead would be about as effective, and a whole lot cheaper and easier to get.
Not to mention Sabre and the VISA credit card processing system -- both use TPF, which is a lot older than Erlang. Meanwhile, many libraries have used the Tandem/Compaq/HP Non-stop system for years -- in fact, I'm pretty sure some have been up without a single interruption since before Erlang was invented. IBM has also had CICS for decades as well; IIRC, it's used by quite a few banks and hotel reservation systems. Likewise, substantial parts of the updates to the Air Traffic Control system currently in progress are being written in various older languages (more in Ada than any other, but it's certainly not the only one).
Now, don't get me wrong: none of these is a panacea for scalable programming. Nonetheless, the people who think they can create highly scalable systems using technology that's a lot more than 10 or 15 years old have some pretty good support. In fact, I can't think of a single really large scale system developed using only technology newer than that.
From a viewpoint of programming languages, there have been quite a few with support for various forms of parallelism over the years. Some (e.g. Concurrent Pascal) were oriented primarily toward tightly coupled processing. Others (e.g. Occam) were oriented primarily toward loosely coupled parallelism.
IMO, you just about need at least some degree of both. You can't take anywhere close to full advantage of a tightly coupled machine using only a loosely-coupled programming model. Likewise, if you want to scale to lots of separate machines, you just about need a more explicitly loosely coupled programming model.
If, however, you use a loosely coupled model even when it's not really appropriate, you may end up needing scalability, even when you otherwise wouldn't -- i.e. your code will be enough slower that it requires multiple machines, even when code using a more appropriate model wouldn't have required it.
Note that said "what you want to do", not "what kind of job you want to do."
The fact is that to an extent you're right: first of all, despite "take your child to work" days, and such, most recent graduates (high school or college) have no clue of what a real job is like. Furthermore, I doubt it's really possible for them to have a really good idea -- you can't have a good idea of what it's like to have the same job for 20 years when you haven't been alive for 20 years, and things like school have changed quite a bit during that time, you can't remember the first few years of your life well at all, etc.
It's also true that if what you really enjoy is something like "hanging out at the beach", it's pretty hard to come up with a paying job doing anything very similar. At the same time, I think most teenagers do enjoy doing at least a few things that could reasonably translate into jobs.
I'd also note that the days of most people getting a job straight out of school, and then staying there until they retire are mostly a bit of history. I wouldn't worry a lot about the fact that you're not sure you're picking out the perfect job right off the bat -- chances are you'll move along to something else before a terribly long time anyway (maybe voluntarily, maybe not).
As such, the first job (or two) is mostly a matter of getting into the work place enough to get a lot better idea of the kinds of things you're good at and enjoy. Mostly before you get that first job you're hoping to find something close enough that you'll at least end up around somebody else who does things you might fit well with.
For those who are uncertain about things, my other bit of advice is to try to find a job at a relatively new, small company. A large corporation will usually have fairly specific job descriptions, and expect you to follow them quite closely. At a small company with relatively little organization, you can often do a lot of what you want as long as what you're doing is (or at least should be) useful. It's often pretty easy to try your hand at a fair number of different kinds of things, and (in a lot of cases) more or less create a niche for yourself doing the ones you're best at/enjoy the most.
Computer science has to do with research into computing, algorithms, etc. Programming, for the most part, is related to software engineering (though some programming also involves computer science). Most of the other jobs you mentioned have nothing to do with either one though.
The simple fact that a job is involved, to some degree or other, with computers, does not mean it has anything to do with computer science. In fact, more often than not, computer science is done with a pencil and paper. Software engineering is typically done with a computer, but primarily to run a text editor or (possibly) something like a UML editor.
Let me give one small example: from a viewpoint of computer science, graphics cards really only come in two varieties: those that you can program, and those that you can ignore. From a viewpoint of software engineering, there's more difference between cards, but it's expressed primarily in terms of the shader model the card implements. If you care much about things like how fast of RAM it has, chances are that neither computer science nor software engineering has much to do with that interest (which isn't to say that a computer scientist can't also enjoy playing a game now and again -- just that he knows the difference between the two).
The OP should really sit back and think about what he wants to do. The simple fact that he hasn't done much, or been taught much about, programming shouldn't be a major handicap if he honestly has a desire and aptitude for doing so.
It's a bit belated, of course, but if he doesn't want to program, he should sit back and think about 1) what he's good at, and 2) what he enjoys. He should then try to come up with jobs that are at least somewhere close to the intersection between the two.
Until or unless he does that, he's pretty much setting himself up for misery, failure, or most likely both. Most people have a hard time enjoying being bad at something for very long, and most people have a hard time caring enough to do things well if they don't enjoy it to at least some degree.
It's drastically different, and if you'd read the previous posts in the thread, this would be obvious. With statically linked libraries, the user can have one application that requires one specific version of the library running alongside another application that requires a different specific version of a library, and never even know there was potential for a conflict.
Shipping the JDK with a Java application isn't like that at all. Yes, if the prescribed version of the JDK is installed with my application, it ensures that my application runs (assuming I've done my job even halfway reasonably, of course). Installing that JDK, however, may break some of their other Java applications -- and the only way to fix them is to re-install some other version of the JDK, and in doing so, breaking mine.
There is also a substantial difference in practicality: static linking adds some to the size of the program, but not anywhere close to the same as the size of the JDK. Installation isn't affected either -- static linking doesn't mean that the installation has to be carried out as root or anything like that -- whereas, the JDK normally should carry precisely such requirements, due (if nothing else) to exactly the problems outlined above.
Of course, with something like VMWare, you can get around even the degree to which Java is broken -- all you have to do is create a separate virtual machine in which to run a separate copy of the OS, on which to run each required Java Virtual Machine. In a decent world such a suggestion could only ever be a joke, and in poor taste at that. In the Java world, it's neither a joke nor even unusual.
Not so. It's true of a language that makes the end user provide/install a large part of the environment in which the program runs. Technically, this isn't a characteristic of the language per se, but of the implementation. Nonetheless, it's not the sort of problem that arises for those who use languages like Fortran, C, C++, Ada, etc.
During development a similar problem can arise -- I can write code that requires a specific version of a specific compiler (or library). Somebody else can write code that requires a different specific compiler or library -- but unlike the situation with Java and such, this does not affect the end user.
Of course, even with a language like this, a programmer can use things like .so's or DLLs (as the case may be) that can lead to problems -- as I said, this is a characteristic of the implementation, not the language. Nonetheless, it's much easier to avoid with something C, C++ or Ada than with something like Java or Python.
I like to write my code once, and it has to be so much more powerful that it can deliver a simple solution, even if the problem may be quite complex.
But then I still use C++ more than anything else, so I'm clearly not "with it."
More accurately, Java is usually more than fast enough, even though it's nearly never as fast as equivalent C++. When you get down to it, performance rarely matters much.
Java doesn't necessarily involve a byte-code interpreter. JVMs have supplied Just In Time compilation for years now.
That's not a panacea though: optimization is generally a difficult task, and good optimization can be quite difficult indeed -- many (perhaps most) NP-complete problems are basically ones of optimization. While optimizing code isn't necessarily identical to a traveling salesman problem (etc.), there is quite a bit in common.
The result of that is that the really difficult optimizations are harder to justify in a JIT compiler. In a traditional compiled language, you compile a small number of times, and run many times. In a JIT environment, you compile far more often, so you can't amortize that cost over nearly as many executions.
I'm not convinced of this either -- Java adds garbage collection, which many people think will save the programmers from themselves. My experience indicates rather the opposite -- garbage collection makes very little difference to memory management, and lack of deterministic finalization makes most other resources considerably more difficult to manage.
There is no one garbage collector in Java -- there's a garbage collector in each individual JVM. Some of them are better than others, and some are optimized for different loads than others. Languages that use manual memory management are similar: each implementation has its own, with its own characteristics.
For that matter, quite a few people use garbage collectors with C and C++. These garbage collectors are generally implemented by extremely good coders as well. C and C++ place a few obstacles in their way, so it's a bit more difficult to implement them, but they work reasonably well nonetheless.
In the end, however, I think the effect of garbage collection on speed of either execution or development seems to be quite exaggerated. In a few circumstances, it's really helpful. In others it's really harmful. Most of the time, it makes very little difference at all.
All but one of those are really just symptoms of one number: the money supply. Look at the price of oil in terms of ounces of gold. Note that the bottom line of this graph is virtually dead flat.
Of those numbers, the only one that isn't an effect of money supply increases is the price of housing in the US -- it's the cause rather than the effect.