I would probably say the opposite. Lisp/scheme is a much more useful data-representation than XML. My eyes hurt by seing the lower expression:-)
Re:Perl as a "scripting" or a "programming" langua
on
Ask Larry Wall
·
· Score: 2
I guess in a strict interpretation, if the language does not recognize the concept of "type", then it could be called "typeless",
Yes, or partially untyped, like C is. As long as two distint types use the same amount of bits in it's representation, C allows you to interpret those bits in any way you like with casts.
but in practice the *concept* permiates many design decisions, such as how the API handles doing math on non-numeric values.
I have no idea what you mean here. If you mean things like pointer arithmetic, I agree, because pointer arithmetic can be quite useful, and I guess some languages have an API for that instead of doing it in the base language like C. Things like vectors, matrices and formulae are usually handled in a typed manner.
But yes, there is room for many different typing schemes in the world of languages. And many successfull languages are in between the three main alternatives (which of course can be subdivided further).
I have never heard of L though...
Re:Perl as a "scripting" or a "programming" langua
on
Ask Larry Wall
·
· Score: 2
Whose's classification system are you using?
English. If the programming system can't somehow tell you or check the type of something, then it isn't a typed system. Hence untyped. But of course, if you can come up with some dynamically typed system not using any form of typecodes, but instead relying on e.g. magic, I'd be happy to say I was wrong.
Obviously, the easiest is to spend your money on some hardware.
But usually, when it comes to text-processing, you can have your cake and eat it too. Have you ever tried to do some text-processing with C++ iostreams? They are dead slow, to the point where you can probably match 100's of Perl regexps while waiting for a simple "cin >> myint" to execute. At least that's my experience with g++ on linux.
So, in reality, you can write a fast Perl program easily, writer a much slower C++ program somewhat less easily, or spend a lot of time writing optimized specialized I/O-routines in C++ for the task at hand.
Why is this so? Perl is optimized for text-processing, and uses smart hand-coded C. C++ iostreams aren't optimized for anything but safety and convenience. I would like C++ to be faster, but in reality it isn't for this kind of task (unless you spend a huge amount of time rewriting the standard libraries).
Re:Perl as a "scripting" or a "programming" langua
on
Ask Larry Wall
·
· Score: 2
According to the camel book, a script is something you give to an actor, while a program is something you give to an audience, so I guess Larry has already answered this one.
By the way. Your definition of dynamically typed languages are far off. If they don't carry typecodes to check types at runtime, then they are not dynamically typed.
If e.g. everything is a string (tcl used to be that way, not too sure anymore), or a machine word (e.g. forth), then it is an untyped language. And there is a large difference between untyped and dynamically typed.
Also, it would be more correct to say that statically typed languages check most types at compile time. An obvious counterexample to "all types" would be an object-oriented language (otherwise dynamic dispatch wouldn't work). Or C, because it allows you to fake anything with casts and unions.
As for what constitutes a scripting language, I think that will be debated for ever, simply because it's not possible to define. Personally, I like Larry's answer in the Camel book.
Well, yes, that is a well-known introductory textbook. Does it really make you "understand" chemistry? No. It would be like saying that reading a good first-year textbook on programming makes you "understand" computer science.
Now, there are some very good computer science first-year textbooks (such as "structure and interpretation of computer programs", which can be read again and again, even by professionals). There are a lot of quite good ones (e.g. "Deitel & Deitel"'s books which cover a relatively broad subject in a traditional way, but fails in being all too thick, uses too many examples, and not offering enough insight to be worth reading again). And there are lot's of bad ones ("Dummies guide to...") that covers only what they think you need to know to do X, and hardly have anything to do with CS or SE.
Zumdahl clearly falls in the "Deitel & Deitel" category. It's good, it's thick as a brick. It is aimed at the average student, not the good ones. It has a lot of boring examples and exercises to skip. And it offers no deep insights that will teach you something new, once you've taken chemistry 101. But it gives you a good overview of the subject, spread with a few simple lies to make the material more accessible to people not already having a clue about chemistry.
What we are looking for is the AOCP, SICP, Cormen/Leiserson/Rivest, Norvig, Garey/Johnson, Foley/van Dam/Feiner/Hughes, GoF, etc... Books that clearly have influenced lot's of practicing programmers and computer scientists. Personally, I doubt there are many. Chemistry is still mostly an experimental science---it's just too damn hard to predict anything that happens, unless somebody has already done the experiment before.
Actually Bill Gates had quite a lot of experience before he started. If you read about his life somewhere (no link, sorry) you will see that he and his friends had made numerous "startups" (well "hobby"-companies) while still at school doing various computing tasks. This is experience that will be helpful when trying to do the real thing (just like writing toy-programs will be helpful when trying to write real ones)
Is to ask your earlier employers, and the businesses you were in contact with at that time...
Personally, in your situation, I would rather flip burgers. If the reason for starting your own business is inability to find work, then it's not going to be easy. Because starting up your own businness is expensive. Both in time and money.
The first thing you should do is to start is to contact local companies telling them that you are in the process of deciding whether to start a local business and see if they are interested. This will give you a chance to see how many paying clients you will get, what kind of work you will get, and how much they are willing to pay.
The second thing you should do is to contact an accountant, preferably someone with experience of helping small startups (i.e. plumbers, hair-salons, etc...). This is important for two reasons:
He will help you make an initial budget. What will your income be, how much will you have to work (i.e. is it better than flipping burgers). And how much will you have to spend just in order to get the business started. This is important, because most likely you will go bankrupt, and it's better to see that in advance, and not start your business, then to actually go bankrupt.
He knows the rules and regulations, and can help you with applying to government for grants to upstart businesses, etc (at least, that's important in my country, don't know about US, but I imagine that such general knowledge would be useful anyway).
I would also consider contacting the employment agencies in your city. They may offer courses, etc..., for people thinking about making a startup. At the very least, they should be able to point you in the direction of somebody who does (again, I don't know about US, but I imagine the situation is similar).
There are a number of pitfalls:
Don't do it because you think it might be easier than finding a job, it isn't!
Don't think that you can work hard at the beginning for no pay and make it work later. If you have no idea of when you can start earning money, chances are that you will not!
Make sure you cover all the expenses of your business in you budget. If you need a room to work in, don't think of it as free because it's in your house. If you need a certification, your company should pay you for your time and money. If you need a better car to look representative to customers, it should be company money. Just because you are your own company doesn't mean you should pay for everything yourself!
And remember that expenses also include your own salary. Your salary should be similar to the salary you would get if you weren't self-employed! Living for free isn't very realistic under any circumstances!
Be realistic about income! Client's will not pay you unrealistic amounts, and it might be hard to find them. A conservative estimate is safer than an optimistic!
Generally you will work harder than if you are someone elses employee, but don't calculate with that in your initial business-plans, you need some slack if everything doesn't work out.
If your main-interest is computing, and not running your own business, consider doing that instead. On the other hand, if you have always dreamed about your own company, it might be worth doing!
Consider your area of expertice, and what you will be selling. If there are already other companies offering that in your area, you are unlikely to be very succesfull competing with them. Make sure your product/idea/area of expertise is unique, and is something lot's of people/businesses would be willing to pay you for. And more importantly, to come back for later.
You have to be a good salesman (a liar). Imagine the carpenter doing a job on your house, and upon seeing (or hearing about) some details of the job he didn't already know about, telling you "Oh, I'm sorry, that's going to be expensive. We will need to do X to get around that, and that will mean that...". If you can't lie with a straight face, you will have a hard time selling things at the right price.
And finally: don't go bankrupt! If you do, you will loose everything in the process. Remember that this might also include such things as your wife, kids, and house!
If you are still interested in starting your own business, then have a go at it. But don't do it because you might think it to be easier than just getting a job.
Well, of course it should be Æ vs æ. There are some languages that actually use that as a letter and not a ligature you know. But I agree that it is a problem...
The reason it behaves this way, is because FAT only used uppercase names, while VFAT allows more reasonable filenames. So files in all uppercase are automatically converted to lowercase since it is likely that it is the result of having travelled on a FAT (not VFAT) medium. And only uppercase is usually annoying.
There is no difference between directories and files. It's just that usually, you don't use file extensions on directories, but if you call you directory QWERTY.txt, case will be preserved.
And, like most annoying behaviour in Windows, there's a way to turn it off: Tools->Options->View->Allow all upppercase filenames. Given the alternatives, I think windows actually did the right thing here. Mainly since the filesystem doesn't care about case anyway, and manually renaming 200 files with uppercase names is annoying. I'd much rather have the system take a guess at something more readable, and have an option to turn it off, if I really want my ALL_CAPS filenames.
Next week, come back to Ask Slashdot: Should filenames be 3117-zP34k-4vv4R3
As you say, there is no convention. And that means that people using.C instead of.cpp,.cxx,.cc or anything else can easily change. It doesn't matter. Renaming all the files in a 1e6k-loc project will take you about 7 minutes (including writing a script to recursively find Makefile's, and sed your way through them).
The only reason for not having case-unsensitivity in the kernel, is to not complicate the kernel, and keep policy out of the kernel. This, on the other hand, is a good reason.
I've never ever seen a beginner having a problem with case-sensitiveness. Any sane, rational, thinking person will see that there are both advantages and disadvantages to both approaches. And once you tell the end-user how your system work (s)he will accept that, and don't worry about it.
The only people who care about minor, but unimportant differences like this are techies, because they are already accustomed to a certain style, and because it is a religious issue they can discuss till the end of time, like vi/emacs, windows/mac/linux/, gnome/kde, etc...
More importantly, I don't care about how user-friendly the command-line is for someone getting confused about case-sensitivity. Users like that should be strapped to their idiot-interface which we can create on top of Unix as well as on Windows. One good example of such an interface is called Bob.
Even todays computer interfaces (which isn't exactly completely suitable for complete morons (noticed the amount of courses for beginning windows users?)) doesn't require you to type a file-name more than once (at first "save"). After that, it's point and click.
My mother can't even use a mouse, or remember the difference between backspace and delete from each time she uses the computer. But I assure you, case-sensitivity is not an issue. There are many things that are confusing her, but understanding that you should use the same name in the same case is not one of them.
Speaking in tongues like the pentecoastals do is evil. It's the devil that's behind it. We all know what the bible told us about the apostles speaking in tongues. Everyone could understand them. But when the pentecoastals speak in tongues, usually only 0 or 1 person understand it.
I'm quite certain that they are all evil, and will go to hell when they die. The devil can take many shapes, and will often present himself as someone else (e.g. a preacher, a beautyful woman, or a politician) in order to lure people into his diabolic schemes. Be careful which sect you are going into!
Is there any language Dijkstra actually liked? I quote:
PL/I, "the fatal disease", belongs more to the problem set than to the solution set.
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
APL is a mistake, carried through to perfection. It is the language of the future for programming techniques of the past: it creates a new generation of coding bums.
It is practically impossible to teach good programming style to students that have had prior exposure to BASIC; as potential programmers they are mentally mutilated beyond hope of regeneration.
Well, I think I might have heard somewhere that he actually said something nice about Algol, but I can't find a quote anywhere.
Anyway, I wouldn't bother too much about what Dijkstra said 10-20 years ago about programming languages long dead. Both FORTRAN, COBOL and PL/1 has clearly proven themselves useful in numerous real-world applications. And contemporary Basic, like Visual Basic shares almost nothing but the name with the kind of BASIC Dijkstra was talking about.
Of course, being a computer scientist, I certainly agree with him, but even I am not doing what I preach. C++ is certainly a large pile of shit, and C isn't much better. Java could almost make it, if it wasn't already so braindamaged by the C/C++ infection. Perl is certainly an offense to anyones aestethics (if people have that these days). Python could almost have made it if it weren't for the completely braindamaged scoping rules, and various other twarts.
Well, guess what languages I use at my workplace? Do I violently disagree? No, because these are the languages that actually do the job, they have fine implementations you can trust, they have lots of available libraries for almost any task, and most people already know them, meaning anyone can pick up where the last person left.
I am not a numeric analyst, so I've never had the use for Fortran, but if that was what I was mostly doing, I would certainly learn it. Learning to speak the lingua franca of numerical analysis will certainly be helpful if that's what you are going to do, even if you don't intend to use it yourself (but you will, trust me - I use C myself for the same reason). And I highly doubt that Fortran 9x is not much nicer than FORTRAN or Fortran 77, numerical people doesn't seem stupid to me, and certainly not as stupid that they would have invented it otherwise.
Yes, but the article did use 1000g, which is exactly what you asked for. Now, of course, if they had said (where g=9.81m/s^2) instead of (gravities, not grams), then maybe more people would understand what they were talking about. And if they wanted to let even more people understand, they could have said (where 1g equals the gravity of earth at sea level).
It is also quite common to use scalar numbers when direction is implied by context, so lowercase g is certainly not always a vector.
Well, you could use the rest of the bits for something else that was useful. E.g sub-second precision or interval-length (for applications that need that).
On the other hand, using the bits for anything else than seconds would probably break applications and libraries which expect time_t to be a count of seconds since the epoch instead of using it as an opaque type. So I guess just making time_t 64 bits is the best solution anyway..
If you chopped off the chasis number on a car you own, it doesn't hurt anyone but yourself.. Why should you go to jail for that?
Well, you do hurt someone, namely the society at large (i.e. taxpayers). The reason the number is there is because it makes it easier for law-enforcement to track the car. It can be used to detect theft, fraud, and several other things. And that saves us (the public) a lot of money.
On the other hand, there's the issue of privacy. We don't want a unique identifiable number on every kind of goods. However, cars do deserve special care, for a number of reasons. First of all, they are pretty expensive, compared to most other things people tend to own, so it's important to track them for that reason. Secondly, they are easy to steal, and easy to transport, so it's more important to be able to identify them than e.g. houses (which can generally be identified by their location). Third, driving a car is not for everybody, it requires a license, for both the driver and the car (a license plate). Having a SSN number for the driver, and a chassis number for the car , helps prevent fraud in this case as well.
It is possible to be for chassis number legislation, but against IMEI number legislation. Cellphones aren't especially expensive, and doesn't require a special license to use (Hell, in Norway where I live, we you can buy both the phone and a phone-card anonymously (pay cash at the dealer, no registration)).
On the other hand, personally I don't see much wrong about making it illegal to change IMEI numbers either. It is (I believe) a real problem, and it is unlikely to make any trouble for most anybody (I can't think of a single reason why you would want to do that, and those I've seen so far in the discussion doesn't seem like something anyone would do). And if you had a legitimate reason, I'm sure you could ask for a permit!
Remember that every complication to the algorithm makes it slower. When you move from linear to quadratic probing, you loose memory locality (think cache). When you move from quadratic probing to double hashing you do another function call (or at least, some calculation). A fibonacci scheme would be similar to quadratic probing, except it requires one more addition, I can't see immediately see any benefits to that, but maybe I'm not thinking hard enough about it...
In the worst case, double hashing is better than quadratic probing, and quadratic probing is better than linear probing. But the trick for finding the "right" method is to ensure that the worst case never happens. Then you can avoid expensive advanced stuff, and keep it simple and lean.
If you don't know much about your data, or your keys, or your insertion/removal pattern, than a separate chaining scheme might be best. If you know everything, then you can use a perfect hash function generator (but even that doesn't necessarily guarantee best performance). The reason they teach you several different methods is because there is no single "best" answer.
I wouldn't worry about King Lear unless you really think it's possible that it would occur in practice. Making your hash function "robust", in that it deals with ridiculously large keys efficiently will slow down everything else. On the other hand, the situation is at least better in C++ than in C, because in C++ std::string remembers the size of a string, so it doesn't have to be recalculated. You could test for the length of a string, and use that to decide between two possible hash functions. Whether it is worth the trouble only profiling will show (I doubt it, unless your input is somewhat strange).
On the other hand, I wonder about where you get the 5 from. This 5 means you need 11 characters to fill all of h. Are your keys really that long on average? Maybe you will get a better hash-distribution if you increased this number somewhat (e.g. 26, as that's the number of letters in the alphabet, it will still give you 5 or 6 "significant" characters). Or you could simplify it by using 32, since that will imply a bit-shift, although that doesn't mean much difference on todays pipelined computers. Again, only profiling will show whether your hash-function can be improved or not.
Slashdot Mirror
I would probably say the opposite. Lisp/scheme is a much more useful data-representation than XML. My eyes hurt by seing the lower expression :-)
Yes, or partially untyped, like C is. As long as two distint types use the same amount of bits in it's representation, C allows you to interpret those bits in any way you like with casts. but in practice the *concept* permiates many design decisions, such as how the API handles doing math on non-numeric values.
I have no idea what you mean here. If you mean things like pointer arithmetic, I agree, because pointer arithmetic can be quite useful, and I guess some languages have an API for that instead of doing it in the base language like C. Things like vectors, matrices and formulae are usually handled in a typed manner.
But yes, there is room for many different typing schemes in the world of languages. And many successfull languages are in between the three main alternatives (which of course can be subdivided further).
I have never heard of L though...
Whose's classification system are you using? English. If the programming system can't somehow tell you or check the type of something, then it isn't a typed system. Hence untyped. But of course, if you can come up with some dynamically typed system not using any form of typecodes, but instead relying on e.g. magic, I'd be happy to say I was wrong.
But usually, when it comes to text-processing, you can have your cake and eat it too. Have you ever tried to do some text-processing with C++ iostreams? They are dead slow, to the point where you can probably match 100's of Perl regexps while waiting for a simple "cin >> myint" to execute. At least that's my experience with g++ on linux.
So, in reality, you can write a fast Perl program easily, writer a much slower C++ program somewhat less easily, or spend a lot of time writing optimized specialized I/O-routines in C++ for the task at hand.
Why is this so? Perl is optimized for text-processing, and uses smart hand-coded C. C++ iostreams aren't optimized for anything but safety and convenience. I would like C++ to be faster, but in reality it isn't for this kind of task (unless you spend a huge amount of time rewriting the standard libraries).
By the way. Your definition of dynamically typed languages are far off. If they don't carry typecodes to check types at runtime, then they are not dynamically typed.
If e.g. everything is a string (tcl used to be that way, not too sure anymore), or a machine word (e.g. forth), then it is an untyped language. And there is a large difference between untyped and dynamically typed.
Also, it would be more correct to say that statically typed languages check most types at compile time. An obvious counterexample to "all types" would be an object-oriented language (otherwise dynamic dispatch wouldn't work). Or C, because it allows you to fake anything with casts and unions.
As for what constitutes a scripting language, I think that will be debated for ever, simply because it's not possible to define. Personally, I like Larry's answer in the Camel book.
Now, there are some very good computer science first-year textbooks (such as "structure and interpretation of computer programs", which can be read again and again, even by professionals). There are a lot of quite good ones (e.g. "Deitel & Deitel"'s books which cover a relatively broad subject in a traditional way, but fails in being all too thick, uses too many examples, and not offering enough insight to be worth reading again). And there are lot's of bad ones ("Dummies guide to...") that covers only what they think you need to know to do X, and hardly have anything to do with CS or SE.
Zumdahl clearly falls in the "Deitel & Deitel" category. It's good, it's thick as a brick. It is aimed at the average student, not the good ones. It has a lot of boring examples and exercises to skip. And it offers no deep insights that will teach you something new, once you've taken chemistry 101. But it gives you a good overview of the subject, spread with a few simple lies to make the material more accessible to people not already having a clue about chemistry.
What we are looking for is the AOCP, SICP, Cormen/Leiserson/Rivest, Norvig, Garey/Johnson, Foley/van Dam/Feiner/Hughes, GoF, etc... Books that clearly have influenced lot's of practicing programmers and computer scientists. Personally, I doubt there are many. Chemistry is still mostly an experimental science---it's just too damn hard to predict anything that happens, unless somebody has already done the experiment before.
Actually Bill Gates had quite a lot of experience before he started. If you read about his life somewhere (no link, sorry) you will see that he and his friends had made numerous "startups" (well "hobby"-companies) while still at school doing various computing tasks. This is experience that will be helpful when trying to do the real thing (just like writing toy-programs will be helpful when trying to write real ones)
Personally, in your situation, I would rather flip burgers. If the reason for starting your own business is inability to find work, then it's not going to be easy. Because starting up your own businness is expensive. Both in time and money.
The first thing you should do is to start is to contact local companies telling them that you are in the process of deciding whether to start a local business and see if they are interested. This will give you a chance to see how many paying clients you will get, what kind of work you will get, and how much they are willing to pay.
The second thing you should do is to contact an accountant, preferably someone with experience of helping small startups (i.e. plumbers, hair-salons, etc...). This is important for two reasons:
I would also consider contacting the employment agencies in your city. They may offer courses, etc..., for people thinking about making a startup. At the very least, they should be able to point you in the direction of somebody who does (again, I don't know about US, but I imagine the situation is similar).
There are a number of pitfalls:
And finally: don't go bankrupt! If you do, you will loose everything in the process. Remember that this might also include such things as your wife, kids, and house!
If you are still interested in starting your own business, then have a go at it. But don't do it because you might think it to be easier than just getting a job.
I disagree. I think the missing file-system on Palm devices reduces its usability a lot.
Well, of course it should be Æ vs æ. There are some languages that actually use that as a letter and not a ligature you know. But I agree that it is a problem...
There is no difference between directories and files. It's just that usually, you don't use file extensions on directories, but if you call you directory QWERTY.txt, case will be preserved.
And, like most annoying behaviour in Windows, there's a way to turn it off: Tools->Options->View->Allow all upppercase filenames. Given the alternatives, I think windows actually did the right thing here. Mainly since the filesystem doesn't care about case anyway, and manually renaming 200 files with uppercase names is annoying. I'd much rather have the system take a guess at something more readable, and have an option to turn it off, if I really want my ALL_CAPS filenames.
Next week, come back to Ask Slashdot: Should filenames be 3117-zP34k-4vv4R3
Correct.
The only reason for not having case-unsensitivity in the kernel, is to not complicate the kernel, and keep policy out of the kernel. This, on the other hand, is a good reason.
The only people who care about minor, but unimportant differences like this are techies, because they are already accustomed to a certain style, and because it is a religious issue they can discuss till the end of time, like vi/emacs, windows/mac/linux/, gnome/kde, etc...
More importantly, I don't care about how user-friendly the command-line is for someone getting confused about case-sensitivity. Users like that should be strapped to their idiot-interface which we can create on top of Unix as well as on Windows. One good example of such an interface is called Bob.
Even todays computer interfaces (which isn't exactly completely suitable for complete morons (noticed the amount of courses for beginning windows users?)) doesn't require you to type a file-name more than once (at first "save"). After that, it's point and click.
My mother can't even use a mouse, or remember the difference between backspace and delete from each time she uses the computer. But I assure you, case-sensitivity is not an issue. There are many things that are confusing her, but understanding that you should use the same name in the same case is not one of them.
Speaking in tongues like the pentecoastals do is evil. It's the devil that's behind it. We all know what the bible told us about the apostles speaking in tongues. Everyone could understand them. But when the pentecoastals speak in tongues, usually only 0 or 1 person understand it.
I'm quite certain that they are all evil, and will go to hell when they die. The devil can take many shapes, and will often present himself as someone else (e.g. a preacher, a beautyful woman, or a politician) in order to lure people into his diabolic schemes. Be careful which sect you are going into!
PL/I, "the fatal disease", belongs more to the problem set than to the solution set.
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
APL is a mistake, carried through to perfection. It is the language of the future for programming techniques of the past: it creates a new generation of coding bums.
It is practically impossible to teach good programming style to students that have had prior exposure to BASIC; as potential programmers they are mentally mutilated beyond hope of regeneration.
Well, I think I might have heard somewhere that he actually said something nice about Algol, but I can't find a quote anywhere.
Anyway, I wouldn't bother too much about what Dijkstra said 10-20 years ago about programming languages long dead. Both FORTRAN, COBOL and PL/1 has clearly proven themselves useful in numerous real-world applications. And contemporary Basic, like Visual Basic shares almost nothing but the name with the kind of BASIC Dijkstra was talking about.
Of course, being a computer scientist, I certainly agree with him, but even I am not doing what I preach. C++ is certainly a large pile of shit, and C isn't much better. Java could almost make it, if it wasn't already so braindamaged by the C/C++ infection. Perl is certainly an offense to anyones aestethics (if people have that these days). Python could almost have made it if it weren't for the completely braindamaged scoping rules, and various other twarts.
Well, guess what languages I use at my workplace? Do I violently disagree? No, because these are the languages that actually do the job, they have fine implementations you can trust, they have lots of available libraries for almost any task, and most people already know them, meaning anyone can pick up where the last person left.
I am not a numeric analyst, so I've never had the use for Fortran, but if that was what I was mostly doing, I would certainly learn it. Learning to speak the lingua franca of numerical analysis will certainly be helpful if that's what you are going to do, even if you don't intend to use it yourself (but you will, trust me - I use C myself for the same reason). And I highly doubt that Fortran 9x is not much nicer than FORTRAN or Fortran 77, numerical people doesn't seem stupid to me, and certainly not as stupid that they would have invented it otherwise.
It is also quite common to use scalar numbers when direction is implied by context, so lowercase g is certainly not always a vector.
So who are you complaining about?
Wow, it would be almost as useful as radio?
Yes, and we all know god intended us to measure in feet and inches instead of meters.
On the other hand, using the bits for anything else than seconds would probably break applications and libraries which expect time_t to be a count of seconds since the epoch instead of using it as an opaque type. So I guess just making time_t 64 bits is the best solution anyway..
Well, you do hurt someone, namely the society at large (i.e. taxpayers). The reason the number is there is because it makes it easier for law-enforcement to track the car. It can be used to detect theft, fraud, and several other things. And that saves us (the public) a lot of money.
On the other hand, there's the issue of privacy. We don't want a unique identifiable number on every kind of goods. However, cars do deserve special care, for a number of reasons. First of all, they are pretty expensive, compared to most other things people tend to own, so it's important to track them for that reason. Secondly, they are easy to steal, and easy to transport, so it's more important to be able to identify them than e.g. houses (which can generally be identified by their location). Third, driving a car is not for everybody, it requires a license, for both the driver and the car (a license plate). Having a SSN number for the driver, and a chassis number for the car , helps prevent fraud in this case as well.
It is possible to be for chassis number legislation, but against IMEI number legislation. Cellphones aren't especially expensive, and doesn't require a special license to use (Hell, in Norway where I live, we you can buy both the phone and a phone-card anonymously (pay cash at the dealer, no registration)).
On the other hand, personally I don't see much wrong about making it illegal to change IMEI numbers either. It is (I believe) a real problem, and it is unlikely to make any trouble for most anybody (I can't think of a single reason why you would want to do that, and those I've seen so far in the discussion doesn't seem like something anyone would do). And if you had a legitimate reason, I'm sure you could ask for a permit!
Am I the only one who can't stop thinking dirty when I hear "fleshmet"?
And this has exactly what to do with radio-signals?
In the worst case, double hashing is better than quadratic probing, and quadratic probing is better than linear probing. But the trick for finding the "right" method is to ensure that the worst case never happens. Then you can avoid expensive advanced stuff, and keep it simple and lean.
If you don't know much about your data, or your keys, or your insertion/removal pattern, than a separate chaining scheme might be best. If you know everything, then you can use a perfect hash function generator (but even that doesn't necessarily guarantee best performance). The reason they teach you several different methods is because there is no single "best" answer.
On the other hand, I wonder about where you get the 5 from. This 5 means you need 11 characters to fill all of h. Are your keys really that long on average? Maybe you will get a better hash-distribution if you increased this number somewhat (e.g. 26, as that's the number of letters in the alphabet, it will still give you 5 or 6 "significant" characters). Or you could simplify it by using 32, since that will imply a bit-shift, although that doesn't mean much difference on todays pipelined computers. Again, only profiling will show whether your hash-function can be improved or not.