Why would physicists be studying this kind of thing?
When you graduate with a PhD in physics, you get three things:
A piece of paper.
A true understanding of how little you understand about the universe.
An unshakable belief that any subject that is not physics is trivia and that you know more about it than people who have spent their lives studying it.
The third means that you are obliged, at least once, to submit a paper about some other field to arxiv.org. Ideally, this paper should not cite any relevant research in the field - only other papers by physicists - and, for bonus points, should base its entire thesis a weak statistical correlation.
It's one of two common transliterations of a Chinese word that roughly translates as life energy. The other is Chi. Neither is a valid word under the rules of Scrabble, which restricts you to English words. Note that this doesn't prevent it from appearing in the official Scrabble dictionary, along with a large number of other words that the rules would disallow. Transliterations of Greek letters (such as pi, mu, tau) are also allowed by the Scrabble word list, but not by any reasonable reading of the rules. If you allow qi, then you can basically allow any foreign word that someone might use in an English sentence (by the same logic, the fact that people say 'je ne sais quoi' in English conversations means that quoi would be a valid Scrabble word).
Re:C6X support is surprising
on
Linux 3.3 Released
·
· Score: 1, Informative
I suspect that this badly-worded Slashdot summary really means that the kernel can now expose the C6x as a device and manage userspace access to it when running on something like an OMAP SoC. Running Linux on the C6x itself would be pointless in the extreme.
Metres. A metre is a measure of length. A meter is a thing you measure with. A metre meter is a stick one metre long. Damn yanks overloading words, it's as if they're speaking C++...
I'm not some super-fucking-nerdburger like you are. When you can explain to me, in English, how I can get a C compiler onto my tablet without having a Ph.D in computer engineering, then I might take notice.
You want to have a C compiler, without knowing anything about computers?
This may be hard for you, in your infinite wisdom, to believe; but some people just want to run code.
Sure, lots of people want to just run code. These people, however, are not the same ones who want a C compiler. The people who want a C compiler, generally, are the ones that want to write C code. If you're not comfortable with compiling code yourself, then perhaps a C compiler is not the sort of application that you want to use.
Being too stupid or ignorant to do your job properly ought to count as negligence, possibly wilful negligence if you had the opportunity to educate yourself but chose not to.
It's a very small step between bending the law to go after people we know are doing something illegal to bending the law to go after people the police or people in power don't like. That's the point of the rule of law: sometimes it protects asshats, but that's better than it not protecting anyone.
The atomic age was not brought about in Europe, but only once Europeans from several nations emigrated to the United States, where they worked in a team of diverse ethnic origins (Germans, Hungarians, Americans, Poles, etc.), something that would've been unthinkable in Europe itself.
Not really. The teams working on nuclear physics were involved in a lot of international collaborations before the second world war. The team working on atom bombs in the UK included people of various nationalities. They were sent to join the Manhattan project because the British government didn't want them to be captured by the Nazis in the event of an invasion.
Umm, no. The grandparent is talking about a language like Pascal, where semicolons are statement separators, not statement terminators. Placing the extra semicolon at the end may significantly alter the semantics of the code, often in quite subtle and difficult-to-debug ways.
For some reason people on slashdot are super anti anyone that says comments are bad
We are, because it's a stupid opinion to hold. Comments are not bad. Redundant comments are bad. There is a really good, simple, way of judging the quality of a codebase: Picking a random function, how much more code do I need to read before I understand what this function is doing and why it's working that way? Clearly named functions and variables go a long way towards explaining what the code is doing, but not necessarily why. Doc comments mean that you don't need to read any of the other functions that are called, just their documentation.
Comments are also invaluable when the code is buggy. They tell you what the author of the code was thinking and therefore what they intended to write, which makes fixing the code much easier.
I've had to maintain code written by people who think comments are bad. In general, I would consider removing their keyboards a good way of improving overall code quality.
Some people will correct you for having variable names over, say, 10 characters
Variable length limits are important if you are using a language like C, where the compiler is not required by the spec to use more than the first 31 characters of an external identifier (which is great for obfuscating code with old compilers, where you can use multiple names to refer to the same identifier). This limit exists for some old binary formats that placed a hard limit on symbol table entries. If you are targeting an embedded system, long names for externals can still chew up a lot of space in the headers, so they're worth shortening to save memory. Elsewhere, the length won't have a detectable impact on performance (except sometimes in load times for large dynamically linked C++ programs).
Beyond that, it's a question of how much information do you need to provide. People need to read your code. Your identifiers should be long enough that people can tell what the identifier is for, but not so long that it is redundant. For example, tmpFile and handleForTemporaryFile (or handle_for_temporary_file) are equally expressive, so there is no advantage in taking one of the longer ones for a local variable. It is conventional to use i, j, and k for loop induction variables in nested loops, so these don't need to be anything different either.
others will tell you NEVER use a goto
Very often the use of goto is a sign of other bad style. For example, I recently reviewed some code that contained a loop with some code at the end to proceed to the next element and a set of gotos at the start to skip over the body. This was easy to refactor by moving the increment to the start and turning the gotos into continues. The resulting code was smaller but, much more importantly, you needed to read less of it to understand what each line was doing. You could read the guard clauses at the top totally independently of the rest of the loop (if this condition is matched, skip to the next loop iteration), you no longer needed to find the goto target and work out what it was doing. I wouldn't say that you should never use goto, just that every time I've seen it used has been hiding some other form of bad style.
others will give you a very hard limit on the number of lines any method should be
The correct limit is that each method should be short enough that you can understand it in isolation. It can do a few complicated things, or a lot of simple things. Hard limits, like the 10 lines you mention, are not bad advice for new programmers: if your method is more than 10 lines long then you should be able to justify why it needs to be so long and why it can't be shortened or split. This is the most important rule of programming: if you can't justify why you're doing something, it's probably wrong.
True, but those who want to write do something else
Yes, we post on Slashdot. After being savaged by grammar nazis and had our arguments ripped to shreds, while getting into the habit of writing several thousand words a day with no proof reading, writing a book seems pretty easy in comparison...
Ask before you make a change. The open source projects I work on all have some projects that can be tackled by a less-experienced programmer with a little bit of hand holding, but which aren't yet a high enough priority for any of the experienced developers to get around to. Often there's a public list of these projects (although it may be out of date), but if you ask you can probably find someone willing to help you make a start, review your code, and give feedback and directions. These days I seem to spend more time doing that than actually writing code...
Why do you think interfacing one language with another is hard? I'm pretty sure it's fairly easy for Python. The Smalltalk compiler that I wrote can seamlessly (and with no overhead) call Objective-C methods and C functions (actually, calling a C function form it is cheaper than sending a Smalltalk message). Taking a Smalltalk program, profiling it, finding the expensive parts, and rewriting those in C is a lot faster than writing the whole thing in C.
Interfacing languages is a solved problem. It can be totally automated. Writing new code is not.
True, to a point, but it eventually gets to the stage where you're implementing a compiler optimisation that is only relevant to a single program, and then there's little advantage in putting it in the compiler rather than the code. One of the things we're working on at the moment is a half-way stage, allowing you to write compiler transforms as plugins, so you can write optimisations for code - write in the high-level language and then a custom transform to do the optimisations you need. This means that you can have different people responsible for the high-level code and the optimisation.
Very rarely, though. On modern architectures, writing high performance assembly language requires a deep knowledge of how everything fits together. Compiler writers spend a lot of time becoming experts in this field
Speaking as a compiler writer... yes and no. The compiler is only as good as the information that it has available to it. For example, I recently tweaked some of my code to be quite a lot faster than the compiler was generating, because I knew several things about the possible input data that were not possible to encode in C.
The compiler has the advantage that it can often look at a large part of the code (including things that seem distantly related in the source) and can perform optimisations everywhere, where a human would probably only apply them in parts that were performance critical. The human has the advantage that the compiler has to be very conservative about the transforms it can apply. The compiler can only do optimisations it can prove - from the visible code - won't alter the program semantics. The human can take shortcuts.
That said, it's very rare for even 1% of the total code to benefit from this kind of optimisation, and it's often already been written in assembly in things like math libraries.
I've hacked on the Python interpreter a bit for a customer, and it's shockingly bad code (and I'm no fan of the language either), but Guido is correct. Most applications spend 90% of their time in less than 10% of the code. It makes sense to use a high-level language and sacrifice performance for the 90% that is not performance critical, and use a faster language that lacks some of the high-level features for the 10% that is. Developer time - especially maintenance time - is expensive, so writing the bits that are not performance critical in a high-level language can save a lot of money without really impacting performance.
Encryption is totally irrelevant. They don't care what you say, they care who you are talking to. This sort of thing is defeated by systems like Tor (or would be, if enough people used it) and anonymous remailers, not by encryption.
A rainbow table for every 256-bit key, using one atom per key, will just about fit in the universe. A rainbow table using one atom for every 266-bit key using one atom per key will be bigger than the universe. Calculating it will probably take a long time, even if you do have a big enough hard disk...
The porn industry wasn't asking for this, because there was no incentive for putting porn on.xxx. First, there is no global definition of what constitutes porn (compare Sweden and Saudi Arabia's definitions for extremes, most of the world is somewhere in the middle). Second, if.xxx is filtered then this gives a strong incentive to have a.com domain. If you're ad-supported, then you don't really care if children see the site - as long as there's some kind of 'click here if you're over 18 thing you're covered. If you're a pay-per-view site, then you're already filtering out anyone who doesn't have a credit card, so you don't gain anything by being on.xxx.
The only people who had an incentive to buy a.xxx domain were ones who owned the.com equivalent and didn't want someone else buying the.xxx version. ICANN even opened registration to these people first for exactly this reason.
Slashdot Mirror
Why would physicists be studying this kind of thing?
When you graduate with a PhD in physics, you get three things:
The third means that you are obliged, at least once, to submit a paper about some other field to arxiv.org. Ideally, this paper should not cite any relevant research in the field - only other papers by physicists - and, for bonus points, should base its entire thesis a weak statistical correlation.
What the hell is a Qi?
It's one of two common transliterations of a Chinese word that roughly translates as life energy. The other is Chi. Neither is a valid word under the rules of Scrabble, which restricts you to English words. Note that this doesn't prevent it from appearing in the official Scrabble dictionary, along with a large number of other words that the rules would disallow. Transliterations of Greek letters (such as pi, mu, tau) are also allowed by the Scrabble word list, but not by any reasonable reading of the rules. If you allow qi, then you can basically allow any foreign word that someone might use in an English sentence (by the same logic, the fact that people say 'je ne sais quoi' in English conversations means that quoi would be a valid Scrabble word).
I suspect that this badly-worded Slashdot summary really means that the kernel can now expose the C6x as a device and manage userspace access to it when running on something like an OMAP SoC. Running Linux on the C6x itself would be pointless in the extreme.
That, and the kernel developers implement the features people are willing to pay them to implement because they have a business need for them.
Given that the compiler has one of the better build systems around, you're right, it isn't. It's probably easier...
Does 'content' mean 'number of Google AdWords'?
Metres. A metre is a measure of length. A meter is a thing you measure with. A metre meter is a stick one metre long. Damn yanks overloading words, it's as if they're speaking C++...
I'm not some super-fucking-nerdburger like you are. When you can explain to me, in English, how I can get a C compiler onto my tablet without having a Ph.D in computer engineering, then I might take notice.
You want to have a C compiler, without knowing anything about computers?
This may be hard for you, in your infinite wisdom, to believe; but some people just want to run code.
Sure, lots of people want to just run code. These people, however, are not the same ones who want a C compiler. The people who want a C compiler, generally, are the ones that want to write C code. If you're not comfortable with compiling code yourself, then perhaps a C compiler is not the sort of application that you want to use.
Being too stupid or ignorant to do your job properly ought to count as negligence, possibly wilful negligence if you had the opportunity to educate yourself but chose not to.
It's a very small step between bending the law to go after people we know are doing something illegal to bending the law to go after people the police or people in power don't like. That's the point of the rule of law: sometimes it protects asshats, but that's better than it not protecting anyone.
I'd love to see some apps that could actually compile code.
So, uh, install some? I copied the PDK headers and libs to mine and cross-compiled LLVM for it. Works fine.
The atomic age was not brought about in Europe, but only once Europeans from several nations emigrated to the United States, where they worked in a team of diverse ethnic origins (Germans, Hungarians, Americans, Poles, etc.), something that would've been unthinkable in Europe itself.
Not really. The teams working on nuclear physics were involved in a lot of international collaborations before the second world war. The team working on atom bombs in the UK included people of various nationalities. They were sent to join the Manhattan project because the British government didn't want them to be captured by the Nazis in the event of an invasion.
Umm, no. The grandparent is talking about a language like Pascal, where semicolons are statement separators, not statement terminators. Placing the extra semicolon at the end may significantly alter the semantics of the code, often in quite subtle and difficult-to-debug ways.
For some reason people on slashdot are super anti anyone that says comments are bad
We are, because it's a stupid opinion to hold. Comments are not bad. Redundant comments are bad. There is a really good, simple, way of judging the quality of a codebase: Picking a random function, how much more code do I need to read before I understand what this function is doing and why it's working that way? Clearly named functions and variables go a long way towards explaining what the code is doing, but not necessarily why. Doc comments mean that you don't need to read any of the other functions that are called, just their documentation.
Comments are also invaluable when the code is buggy. They tell you what the author of the code was thinking and therefore what they intended to write, which makes fixing the code much easier.
I've had to maintain code written by people who think comments are bad. In general, I would consider removing their keyboards a good way of improving overall code quality.
Some people will correct you for having variable names over, say, 10 characters
Variable length limits are important if you are using a language like C, where the compiler is not required by the spec to use more than the first 31 characters of an external identifier (which is great for obfuscating code with old compilers, where you can use multiple names to refer to the same identifier). This limit exists for some old binary formats that placed a hard limit on symbol table entries. If you are targeting an embedded system, long names for externals can still chew up a lot of space in the headers, so they're worth shortening to save memory. Elsewhere, the length won't have a detectable impact on performance (except sometimes in load times for large dynamically linked C++ programs).
Beyond that, it's a question of how much information do you need to provide. People need to read your code. Your identifiers should be long enough that people can tell what the identifier is for, but not so long that it is redundant. For example, tmpFile and handleForTemporaryFile (or handle_for_temporary_file) are equally expressive, so there is no advantage in taking one of the longer ones for a local variable. It is conventional to use i, j, and k for loop induction variables in nested loops, so these don't need to be anything different either.
others will tell you NEVER use a goto
Very often the use of goto is a sign of other bad style. For example, I recently reviewed some code that contained a loop with some code at the end to proceed to the next element and a set of gotos at the start to skip over the body. This was easy to refactor by moving the increment to the start and turning the gotos into continues. The resulting code was smaller but, much more importantly, you needed to read less of it to understand what each line was doing. You could read the guard clauses at the top totally independently of the rest of the loop (if this condition is matched, skip to the next loop iteration), you no longer needed to find the goto target and work out what it was doing. I wouldn't say that you should never use goto, just that every time I've seen it used has been hiding some other form of bad style.
others will give you a very hard limit on the number of lines any method should be
The correct limit is that each method should be short enough that you can understand it in isolation. It can do a few complicated things, or a lot of simple things. Hard limits, like the 10 lines you mention, are not bad advice for new programmers: if your method is more than 10 lines long then you should be able to justify why it needs to be so long and why it can't be shortened or split. This is the most important rule of programming: if you can't justify why you're doing something, it's probably wrong.
True, but those who want to write do something else
Yes, we post on Slashdot. After being savaged by grammar nazis and had our arguments ripped to shreds, while getting into the habit of writing several thousand words a day with no proof reading, writing a book seems pretty easy in comparison...
Ask before you make a change. The open source projects I work on all have some projects that can be tackled by a less-experienced programmer with a little bit of hand holding, but which aren't yet a high enough priority for any of the experienced developers to get around to. Often there's a public list of these projects (although it may be out of date), but if you ask you can probably find someone willing to help you make a start, review your code, and give feedback and directions. These days I seem to spend more time doing that than actually writing code...
I was going to point out that dead comedians tended not to be very funny. Then I remembered that you were comparing them to Russell Brand...
Why do you think interfacing one language with another is hard? I'm pretty sure it's fairly easy for Python. The Smalltalk compiler that I wrote can seamlessly (and with no overhead) call Objective-C methods and C functions (actually, calling a C function form it is cheaper than sending a Smalltalk message). Taking a Smalltalk program, profiling it, finding the expensive parts, and rewriting those in C is a lot faster than writing the whole thing in C.
Interfacing languages is a solved problem. It can be totally automated. Writing new code is not.
True, to a point, but it eventually gets to the stage where you're implementing a compiler optimisation that is only relevant to a single program, and then there's little advantage in putting it in the compiler rather than the code. One of the things we're working on at the moment is a half-way stage, allowing you to write compiler transforms as plugins, so you can write optimisations for code - write in the high-level language and then a custom transform to do the optimisations you need. This means that you can have different people responsible for the high-level code and the optimisation.
Very rarely, though. On modern architectures, writing high performance assembly language requires a deep knowledge of how everything fits together. Compiler writers spend a lot of time becoming experts in this field
Speaking as a compiler writer... yes and no. The compiler is only as good as the information that it has available to it. For example, I recently tweaked some of my code to be quite a lot faster than the compiler was generating, because I knew several things about the possible input data that were not possible to encode in C.
The compiler has the advantage that it can often look at a large part of the code (including things that seem distantly related in the source) and can perform optimisations everywhere, where a human would probably only apply them in parts that were performance critical. The human has the advantage that the compiler has to be very conservative about the transforms it can apply. The compiler can only do optimisations it can prove - from the visible code - won't alter the program semantics. The human can take shortcuts.
That said, it's very rare for even 1% of the total code to benefit from this kind of optimisation, and it's often already been written in assembly in things like math libraries.
I've hacked on the Python interpreter a bit for a customer, and it's shockingly bad code (and I'm no fan of the language either), but Guido is correct. Most applications spend 90% of their time in less than 10% of the code. It makes sense to use a high-level language and sacrifice performance for the 90% that is not performance critical, and use a faster language that lacks some of the high-level features for the 10% that is. Developer time - especially maintenance time - is expensive, so writing the bits that are not performance critical in a high-level language can save a lot of money without really impacting performance.
Encryption is totally irrelevant. They don't care what you say, they care who you are talking to. This sort of thing is defeated by systems like Tor (or would be, if enough people used it) and anonymous remailers, not by encryption.
A rainbow table for every 256-bit key, using one atom per key, will just about fit in the universe. A rainbow table using one atom for every 266-bit key using one atom per key will be bigger than the universe. Calculating it will probably take a long time, even if you do have a big enough hard disk...
The porn industry wasn't asking for this, because there was no incentive for putting porn on .xxx. First, there is no global definition of what constitutes porn (compare Sweden and Saudi Arabia's definitions for extremes, most of the world is somewhere in the middle). Second, if .xxx is filtered then this gives a strong incentive to have a .com domain. If you're ad-supported, then you don't really care if children see the site - as long as there's some kind of 'click here if you're over 18 thing you're covered. If you're a pay-per-view site, then you're already filtering out anyone who doesn't have a credit card, so you don't gain anything by being on .xxx.
The only people who had an incentive to buy a .xxx domain were ones who owned the .com equivalent and didn't want someone else buying the .xxx version. ICANN even opened registration to these people first for exactly this reason.