Computer source code, thought unintelligible to many is the preferred method of communication among computer programmers.
"that's like saying bridges are the preferred method of communication among civil engineers. code is for compilers, text is for people."
Source code *is* text, except in languages like National Instruments' LabView.
Blueprints and engineering drawings, not bridges, are a suitable method of communication between civil engineers. They can be "converted" to bridges by builders reading the blueprints. That does not destroy their value as a medium of communication.
Source code is a way to express an algorithm in a way that it may be *both* understood by humans and converted into executable form.
The court specifically recognized that the corresponding object code would not be a medium of human-human communication, but rather in the nature of a mechanical device.
The quote you made from the decision is in the context of discussions of encryption. Surely, for a complicated encryption algorithm, the clearest, most precise, and most unambiguous expression would be a code-like representation, whether in pseudo-code or a real programming language.
Are you suggesting that bridge designers communicating with bridge builders by text alone would work? Do you think the bridge would at all resemble the true intentions of the designer? Would it even be safe to walk across? I believe we would clearly prefer that communication to take place through accurate drawings.
Likewise, discussions between cryptographers and people implementing encryption systems would almost certainly be most accurate if conducted using code-like constructions. Accurate descriptions of encryption technology are essential to avoid potentially serious errors, such as security flaws. Therefore, communication in source code is far preferable to ordinary text.
My GF used to get annoyed that a lot of cell phone providers and travel-related companies had phone reps who knew less about the details of their various service plans than she did.
My explanation is that "if they were smart enough to understand all the details of these plans, they wouldn't have a job answering the phone."
This is completely impractical. Most of the time, bad error handling is a cancer that afflicts the whole application. Open source isn't much help when it takes a whole re-write to do things right.
On an airplane, the interior pressure is usually regulated to 10,000 ft above sea level.
Basically, this is a standard limit, which means that the components have been designed to be able to be shipped by air freight, without being damaged due to pressure changes.
Sitting in a plane at 35,000 ft, there is really no difference in the operating environment from 10,000 ft (except "in case of a loss of cabin pressure, oxygen masks will deploy automatically...")
Re:I'm buying one purely for the tiny firewire hd
on
Apple releases iPod
·
· Score: 1
I like the iPod. I think it compares favorably in price with the higher capacity Rios (which surprised me.)
I think it'll sell as well as the G4 Cube. Oops;-)
The typesetting engine in TeX was designed to run on systems prevalent in 1982 (when TeX was officially feature-frozen by Donald Knuth). I think anything that hasn't grown in 20 years is unlikely to be bloated by any reasonable standard. LaTeX is continuing to evolve, but it is simply a set of more user-friendly macros, and does not add significant bloat.
As an aside, please don't insult Common Lisp by conflating it with Emacs Lisp, a crippled Lisp variant. (I won't argue that Emacs isn't bloated, just that the additional bloat caused by w3, etc., is the side-effect of including a very powerful user scripting model. If MS Word were bloated only because the user community contributed lots of VBA code that MS decided to install by default with Word, then it might be a fairer comparison.)
The point is that a few very good programmers using Common Lisp beats far and away the same number of *equally good* programmers working in C/C++.
The fact that a few very good programmers kicks ass over a large group of mediocre programmers is not about Lisp. It is about mediocrity.
The question shouldn't be "what tool do I get to protect mediocre/incompetent programmers from their own weakness" but "how do I get great programmers"? One way, is to let the great programmers use the language that lets them work best.
Programming well is hard enough. Why make it harder by forcing every one to use tools made for the lowest common denominator?
And if you do get mediocre programmers, either train them or dump them. True incompetence will harm your project, no matter what language you use. Inexperience or ignorance can be conquered by training.
What's the problem? The purpose of the Common Lisp "loop" macro was to develop an easy, almost English-like way to describe iteration. For those who don't know it, it has a lot of "clauses" to describe the various phases of initialization, stepping, testing, and collecting results, which get combined in an almost free-form way.
It includes things like the C for loop, but a lot more as well. [from the Hyperspec]
(loop for x from 1 to 10
for y = nil then x
collect (list x y))
;; Collect numbers larger than 3.
(loop for i in '(1 2 3 4 5 6)
when (and (> i 3) i)
collect it) ; IT refers to (and (> i 3) i).
=> (4 5 6)
You don't have to use LOOP if you don't like it. It is a bit of a mess, when different clauses start interacting, but it can be very clear when the other iteration mechanisms might be more confusing.
Sorry if I was being harsh, but there is an important difference between "interpreted" and "interactive." Macintosh Common Lisp, for instance, compiles everything to native code, but is still just as interactive as an interpreter. Since compilation can act on individual functions, it is very fast, and the overhead is completely negligible. I enter (+ 3 5) and get 8 back without a blink. Many people use the "Lisp is interpreted, therefore slow and inefficient" myth as a way to dismiss it.
More typically (CMU CL), when you type things by hand, including function definitions, they are held in interpreted form, which is more flexible for tracing, debugging, introspection, etc. You have to add the extra step of asking things to be compiled. You can ask for individual function definitions to be compiled, or for whole source files. Much of the work that went into Common Lisp was to ensure that compiled code and interpreted code have exactly the same semantics, unlike the original Lisp implementations.
I haven't done work on the PC, but at least on Mac and Unix, it is de rigueur to support a foreign function interface to libraries that follow the native linkage format (C, Fortran, etc.) In the other direction, things are a little more limited, as Lisp has a pretty elaborate run-time environment, that can be difficult to access from more primitive environments like C.
If you mean linking to Lisp libraries, then I believe that the shipped binaries would have to be Lisp platform specific. I.e. Franz "fast load libraries" have a different format from Xanalys.
I've heard a lot of talk on comp.lang.lisp about the use of CORBA as a mechanism to solve a lot of these inter-language problems. Lisp provides a very good platform for using such protocols.
Your use of "interpreted functional languages" indicates an ignorance of current Lisp practice. Lisp implementations typically *compile* to efficient native code. Even if you ask it to compile a new function at run-time.
You've also omitted all the problems of re-linking C++ code after you've compiled it, and forgotten about the problem of what to do when you re-define a base class. When the class members all change their positions, how do you go back and fix all the accessors? In C++ you need to do a full recompile of the system. Not so in Lisp.
C++ templates are an impressive hack, but are much less elegant than Lisp macros (the macro expansion is described in the Lisp language itself, so there isn't any new, messy syntax.) Plus, templates lead to enormous code bloat.
C++ has no elegant way to specialize on multiple arguments of a method, because C++ methods are tied to classes. "friend" is a symptom of this disease.
Sure, you can use various "patterns" to get around weaknesses in the C++ object model, but why should you have to?
Also, when you re-define a class, you have to recompile your C++ program. Which means it has to stop running. Neither is true in CLOS. You can interupt a CL program, re-define a class, write code (if necessary) which updates older instances to work as instances of the re-defined class, on demand, and then continue execution, perhaps after you've interactively tried your new class definition.
The point about the CL standard, as opposed to most other popular standards, is that it aimed to standardize *existing practice*. The standardization process was meant to ensure that several vendors could develop implementations of Lisp with which Lisp developers could use common code. ("Common," get it?) It was meant to eliminate the basic but gratuitous incompatibilities that made it hard to port code between previous dialects of Lisp. It was based very heavily on the many years of experience with various Lisp dialects (e.g., various ways to implement OOP) to decide what was worth mandating as "minimum acceptable", and what wasn't.
What this means is that most of Common Lisp is useful and WORKS RIGHT. As opposed, for instance, to C++, where much of the standard was based on Stroustrup et al. mucking around with their idea of how things should work, with very little real world experience using the language. Or Fortran 90, which I think was an ultimate "language designed by committee."
Furthermore, the standard isn't the be-all and end-all of Lisp. It's just the basic foundation. Lisp implementations are free to have all the "pretty" libraries they want, presumably determined by what customers ask their vendors to provide. When it all gets shaken out, and the community can determine what should be accepted practice, THEN we can standardize.
Who needs bytecodes when you have robust native-code compilation available at run-time? If you really need to run code on the client, emit Java bytecodes.
As I recall, what you were contending is that somewhere in the universe, there was some pocket of matter than may have been cooled lower than the matter in this experiment (20 *nano*Kelving).
1) you don't seem to understand the cooling. You just describe one-D confinement. They are different. You gloss over or omit the high-field seekers and low-field seekers. You talk about *plasma* which is a VERY HOT STATE of matter. Cooling to fractional-K temperatures by magnetic fields is of NEUTRAL species with magnetic moments. NOT PLASMAS.
2) even if I concede that somehow this field setup occurs accidentally in already cold regions, and cools, unlike your description of bottling, you still have a huge way to go to get EIGHT ORDERS OF MAGNITUDE cooler to get from 2K to 20nK.
This is NOT GOING TO HAPPEN. EVER. Even if you wait an enormously longer time than the age of the universe.
You are wrong about magnetic cooling. Magnetic fields (actually, gradients) don't do the cooling, although they can cause confinement of particles of one particular magnetic moment, if the particles are already cool enough.
One way to get cooling by manipulating magnetic fields is to evaporatively cool the (spin-polarized) trap contents, by lowering the magnetic gradient which is maintaining the potential well, allowing the hotter confined particles to escape, leaving only the cooler ones behind.
Anyhow, even if through some bizarre coincidence this kind of magnetic field gradient occured by accident (in three-dimensions simultaneously), somewhere in interstellar space, nothing has happened to shield the matter from the microwave background. You can't hide behind intergalactic dust clouds, which are warmer than the background anyway, from absorbing the radiation that they block.
Who knows how much intelligent life there is in the universe? Sure the universe is a big place, but who's to say the probability of life arising or intelligence arising is either relatively high or unbelievably low? Life on Earth was pretty damn simple and unintelligent for most of its history, and showed no real promise of producing anything smarter than a trilobite for a very long time. Plus, these intelligent beings have to also care about low-temperature physics, and have a Bose & Einstein to guide them. Doesn't seem very likely to me.
That's a good one. Also an old one. Most slashdot readers probably are too old to remember all the "electricity too cheap to meter" claims for nuclear power back in the 50s.
Not that I am against nuclear power. I'm just in favor of realistic expectations.
No. Band theory of solids has nothing to do with the Standard Model or string theory that is being tested by accelerators. That's like saying
"implementing Quake 9 boils down to using C, which is very important in implementing the Linux kernel...." So what? Any code written for Quake 9 doesn't advance Linux kernel work at all. Do you see any solid state physicists lining up to say "band theory will grind to a halt unless you fund this collider"?
Materials scientists already do a lot of good work on understanding materials and how to design good new ones. Like high-temperature superconductors, for instance. They owe more to chemists than high energy physicists.
Yeah, but logic theory was cheap. They didn't come with cups in their hands saying "give me billions of dollars for something that might be useful in the unforeseeable future." What about all the math done at the time that is still useless? I guess you just didn't bother to learn that. For good reason.
Of course, these theories predict energy ranges "just within the reach of newly proposed accelerators." Once those accelerators are built and see nothing, the theorists will come back with adjustments so that they are "just beyond the reach of current accelerators, but within the reach of the next generation...."
How convenient. The Higgs mass keeps creeping up as well.
It is also highly misleading to credit high energy physics of the early 20th century with the development of semiconductor technology. This field owed very little to high energy research of any kind. Basic quantum mechanics was done to solve problems of atomic physics and thermodynamics (i.e. problems that even chemists would have recognized at the time), and then very quickly (even by Einstein) applied to solid state problems. The people who did cosmic ray (high-energy) research went nowhere.
Basically, the energies probed by these accelerators explore degrees of freedom that are frozen out at room temperature. This physics may have had important practical applications if we were living three seconds after the big bang, but now, a few billion years later, things have cooled down to pretty low energies. That's why we have to spend billions of dollars to recreate high-energy conditions again. Don't fool yourself that this has any future practical impact.
Well, actually, there's no harm in fooling yourself. Just don't try to fool others.
You are right, of course, but you've simply wrapped all the strangeness up into a vaguely definable "collapse" of the wavefunction. Which I feel favors the latter statement.
This collapse can't really be treated rigorously, because the Schroedinger equation that evolves the wavefunction either has a simple Hamiltonian (the system) which causes linear time evolution (i.e. can't collapse, just rotate in state space), or includes a coupling to a vaguely defined "macroscopic" system which is not in a coherent quantum state. The interaction terms are what give rise to the "collapse" of the components that refer to the microscopic system.
Unfortunately, there is no way to really figure out physically where the incoherence of the big system came from. The incoherence is really more a statement either about ignorance of the true quantum state, which is a cop-out, because then you've forced a collapse on a state that is actually not going to collapse, or about the limitations of being able to set up a macroscopic system in a pure state, because you are at finite temperature, and don't have 10^100 years or whatever to prepare the system carefully enough to resolve the quantum levels of the system. I find this thermodynamic argument persuasive (i.e. it is really what happens), but still philosophically unsatisfying (i.e. it really doesn't physically explain where the thermal disorder comes from, if the universe as a whole is a quantum mechanical system.)
My personal opinion is that there isn't really any great philosophy that can be discovered by thinking about this much harder.
It doesn't necessarily "change the state" of the second particle. (It can't, since the particles cannot causally interact; the particle's state evolves according to the local environment). However, the results of measurements on the second particle are inter-dependent with the results of the measurements of the first particle, even though the acts of measurement themselves cannot be connected causally (in the sense of special relativity).
The really funky thing is that the *choice* made to determine what kind of measurement to make on the first particle affects the inter-dependence. The idea being that "somehow" the measurement apparatus is communicating its setup to the distant particle, even though it really can't. This is really disturbing, but probably doesn't have any better explanation than "that's just how it is."
Your treatment of lefties is either incomplete or confusing. "Main button would be as large as possible." Operated by the index finger? Then it has to be on both sides of the mouse. Creating two equally large buttons creates the question "which one is really the main button." "Thumb side mounted jog wheel." Two of those, right?
As far as configuring the buttons with software, that's a real hassle, and doesn't change the hardware to be any more comfortable.
For me, this is the key reason to favor one-button mice. Lefties and righties are perfectly equal.
Bill Gates is a lefty, but he learned to use a mouse with his right hand, because "it isn't really that hard." Why should it be any effort at all?
Slashdot Mirror
A 100 yen piece is exactly the right size to open the battery compartment on a Japanese camera.
Computer source code, thought unintelligible to many is the preferred method of communication among computer programmers.
"that's like saying bridges are the preferred method of communication among civil engineers. code is for compilers, text is for people."
Source code *is* text, except in languages like National Instruments' LabView.
Blueprints and engineering drawings, not bridges, are a suitable method of communication between civil engineers. They can be "converted" to bridges by builders reading the blueprints. That does not destroy their value as a medium of communication.
Source code is a way to express an algorithm in a way that it may be *both* understood by humans and converted into executable form.
The court specifically recognized that the corresponding object code would not be a medium of human-human communication, but rather in the nature of a mechanical device.
The quote you made from the decision is in the context of discussions of encryption. Surely, for a complicated encryption algorithm, the clearest, most precise, and most unambiguous expression would be a code-like representation, whether in pseudo-code or a real programming language.
Are you suggesting that bridge designers communicating with bridge builders by text alone would work? Do you think the bridge would at all resemble the true intentions of the designer? Would it even be safe to walk across? I believe we would clearly prefer that communication to take place through accurate drawings.
Likewise, discussions between cryptographers and people implementing encryption systems would almost certainly be most accurate if conducted using code-like constructions. Accurate descriptions of encryption technology are essential to avoid potentially serious errors, such as security flaws. Therefore, communication in source code is far preferable to ordinary text.
My GF used to get annoyed that a lot of cell phone providers and travel-related companies had phone reps who knew less about the details of their various service plans than she did.
My explanation is that "if they were smart enough to understand all the details of these plans, they wouldn't have a job answering the phone."
This is completely impractical. Most of the time, bad error handling is a cancer that afflicts the whole application. Open source isn't much help when it takes a whole re-write to do things right.
I believe you are thinking too hard about this.
On an airplane, the interior pressure is usually regulated to 10,000 ft above sea level.
Basically, this is a standard limit, which means that the components have been designed to be able to be shipped by air freight, without being damaged due to pressure changes.
Sitting in a plane at 35,000 ft, there is really no difference in the operating environment from 10,000 ft (except "in case of a loss of cabin pressure, oxygen masks will deploy automatically...")
I like the iPod. I think it compares favorably in price with the higher capacity Rios (which surprised me.)
;-)
I think it'll sell as well as the G4 Cube. Oops
Caught me.
The typesetting engine in TeX was designed to run on systems prevalent in 1982 (when TeX was officially feature-frozen by Donald Knuth). I think anything that hasn't grown in 20 years is unlikely to be bloated by any reasonable standard. LaTeX is continuing to evolve, but it is simply a set of more user-friendly macros, and does not add significant bloat.
As an aside, please don't insult Common Lisp by conflating it with Emacs Lisp, a crippled Lisp variant. (I won't argue that Emacs isn't bloated, just that the additional bloat caused by w3, etc., is the side-effect of including a very powerful user scripting model. If MS Word were bloated only because the user community contributed lots of VBA code that MS decided to install by default with Word, then it might be a fairer comparison.)
The point is that a few very good programmers using Common Lisp beats far and away the same number of *equally good* programmers working in C/C++.
The fact that a few very good programmers kicks ass over a large group of mediocre programmers is not about Lisp. It is about mediocrity.
The question shouldn't be "what tool do I get to protect mediocre/incompetent programmers from their own weakness" but "how do I get great programmers"? One way, is to let the great programmers use the language that lets them work best.
Programming well is hard enough. Why make it harder by forcing every one to use tools made for the lowest common denominator?
And if you do get mediocre programmers, either train them or dump them. True incompetence will harm your project, no matter what language you use. Inexperience or ignorance can be conquered by training.
What's the problem? The purpose of the Common Lisp "loop" macro was to develop an easy, almost English-like way to describe iteration. For those who don't know it, it has a lot of "clauses" to describe the various phases of initialization, stepping, testing, and collecting results, which get combined in an almost free-form way.
It includes things like the C for loop, but a lot more as well. [from the Hyperspec]
(loop for x from 1 to 10
for y = nil then x
collect (list x y))
=> ((1 NIL) (2 2) (3 3) (4 4) (5 5) (6 6) (7 7) (8 8) (9 9) (10 10))
;; Collect numbers larger than 3.
(loop for i in '(1 2 3 4 5 6)
when (and (> i 3) i)
collect it) ; IT refers to (and (> i 3) i).
=> (4 5 6)
You don't have to use LOOP if you don't like it. It is a bit of a mess, when different clauses start interacting, but it can be very clear when the other iteration mechanisms might be more confusing.
How would you prefer the syntax to look?
Sorry if I was being harsh, but there is an important difference between "interpreted" and "interactive." Macintosh Common Lisp, for instance, compiles everything to native code, but is still just as interactive as an interpreter. Since compilation can act on individual functions, it is very fast, and the overhead is completely negligible. I enter (+ 3 5) and get 8 back without a blink. Many people use the "Lisp is interpreted, therefore slow and inefficient" myth as a way to dismiss it.
More typically (CMU CL), when you type things by hand, including function definitions, they are held in interpreted form, which is more flexible for tracing, debugging, introspection, etc. You have to add the extra step of asking things to be compiled. You can ask for individual function definitions to be compiled, or for whole source files. Much of the work that went into Common Lisp was to ensure that compiled code and interpreted code have exactly the same semantics, unlike the original Lisp implementations.
I haven't done work on the PC, but at least on Mac and Unix, it is de rigueur to support a foreign function interface to libraries that follow the native linkage format (C, Fortran, etc.) In the other direction, things are a little more limited, as Lisp has a pretty elaborate run-time environment, that can be difficult to access from more primitive environments like C.
If you mean linking to Lisp libraries, then I believe that the shipped binaries would have to be Lisp platform specific. I.e. Franz "fast load libraries" have a different format from Xanalys.
I've heard a lot of talk on comp.lang.lisp about the use of CORBA as a mechanism to solve a lot of these inter-language problems. Lisp provides a very good platform for using such protocols.
Your use of "interpreted functional languages" indicates an ignorance of current Lisp practice. Lisp implementations typically *compile* to efficient native code. Even if you ask it to compile a new function at run-time.
You've also omitted all the problems of re-linking C++ code after you've compiled it, and forgotten about the problem of what to do when you re-define a base class. When the class members all change their positions, how do you go back and fix all the accessors? In C++ you need to do a full recompile of the system. Not so in Lisp.
C++ templates are an impressive hack, but are much less elegant than Lisp macros (the macro expansion is described in the Lisp language itself, so there isn't any new, messy syntax.) Plus, templates lead to enormous code bloat.
C++ has no elegant way to specialize on multiple arguments of a method, because C++ methods are tied to classes. "friend" is a symptom of this disease.
Sure, you can use various "patterns" to get around weaknesses in the C++ object model, but why should you have to?
Also, when you re-define a class, you have to recompile your C++ program. Which means it has to stop running. Neither is true in CLOS. You can interupt a CL program, re-define a class, write code (if necessary) which updates older instances to work as instances of the re-defined class, on demand, and then continue execution, perhaps after you've interactively tried your new class definition.
Still think C++ really supports OOP?
The point about the CL standard, as opposed to most other popular standards, is that it aimed to standardize *existing practice*. The standardization process was meant to ensure that several vendors could develop implementations of Lisp with which Lisp developers could use common code. ("Common," get it?) It was meant to eliminate the basic but gratuitous incompatibilities that made it hard to port code between previous dialects of Lisp. It was based very heavily on the many years of experience with various Lisp dialects (e.g., various ways to implement OOP) to decide what was worth mandating as "minimum acceptable", and what wasn't.
What this means is that most of Common Lisp is useful and WORKS RIGHT. As opposed, for instance, to C++, where much of the standard was based on Stroustrup et al. mucking around with their idea of how things should work, with very little real world experience using the language. Or Fortran 90, which I think was an ultimate "language designed by committee."
Furthermore, the standard isn't the be-all and end-all of Lisp. It's just the basic foundation. Lisp implementations are free to have all the "pretty" libraries they want, presumably determined by what customers ask their vendors to provide. When it all gets shaken out, and the community can determine what should be accepted practice, THEN we can standardize.
Who needs bytecodes when you have robust native-code compilation available at run-time? If you really need to run code on the client, emit Java bytecodes.
I assume you looked up previous research in "CDR coding," a well-known technique storing lists in consecutive memory locations by default.
This was widely used by machines that understood Lisp at the hardware level.
As I recall, what you were contending is that somewhere in the universe, there was some pocket of matter than may have been cooled lower than the matter in this experiment (20 *nano*Kelving).
1) you don't seem to understand the cooling. You just describe one-D confinement. They are different. You gloss over or omit the high-field seekers and low-field seekers. You talk about *plasma* which is a VERY HOT STATE of matter. Cooling to fractional-K temperatures by magnetic fields is of NEUTRAL species with magnetic moments. NOT PLASMAS.
2) even if I concede that somehow this field setup occurs accidentally in already cold regions, and cools, unlike your description of bottling, you still have a huge way to go to get EIGHT ORDERS OF MAGNITUDE cooler to get from 2K to 20nK.
This is NOT GOING TO HAPPEN. EVER. Even if you wait an enormously longer time than the age of the universe.
You are wrong about magnetic cooling. Magnetic fields (actually, gradients) don't do the cooling, although they can cause confinement of particles of one particular magnetic moment, if the particles are already cool enough.
One way to get cooling by manipulating magnetic fields is to evaporatively cool the (spin-polarized) trap contents, by lowering the magnetic gradient which is maintaining the potential well, allowing the hotter confined particles to escape, leaving only the cooler ones behind.
Anyhow, even if through some bizarre coincidence this kind of magnetic field gradient occured by accident (in three-dimensions simultaneously), somewhere in interstellar space, nothing has happened to shield the matter from the microwave background. You can't hide behind intergalactic dust clouds, which are warmer than the background anyway, from absorbing the radiation that they block.
Who knows how much intelligent life there is in the universe? Sure the universe is a big place, but who's to say the probability of life arising or intelligence arising is either relatively high or unbelievably low? Life on Earth was pretty damn simple and unintelligent for most of its history, and showed no real promise of producing anything smarter than a trilobite for a very long time. Plus, these intelligent beings have to also care about low-temperature physics, and have a Bose & Einstein to guide them. Doesn't seem very likely to me.
"unlimited, clean, electricity"
That's a good one. Also an old one. Most slashdot readers probably are too old to remember all the "electricity too cheap to meter" claims for nuclear power back in the 50s.
Not that I am against nuclear power. I'm just in favor of realistic expectations.
No. Band theory of solids has nothing to do with the Standard Model or string theory that is being tested by accelerators. That's like saying
"implementing Quake 9 boils down to using C, which is very important in implementing the Linux kernel...." So what? Any code written for Quake 9 doesn't advance Linux kernel work at all. Do you see any solid state physicists lining up to say "band theory will grind to a halt unless you fund this collider"?
Materials scientists already do a lot of good work on understanding materials and how to design good new ones. Like high-temperature superconductors, for instance. They owe more to chemists than high energy physicists.
Yeah, but logic theory was cheap. They didn't come with cups in their hands saying "give me billions of dollars for something that might be useful in the unforeseeable future." What about all the math done at the time that is still useless? I guess you just didn't bother to learn that. For good reason.
Of course, these theories predict energy ranges "just within the reach of newly proposed accelerators." Once those accelerators are built and see nothing, the theorists will come back with adjustments so that they are "just beyond the reach of current accelerators, but within the reach of the next generation...."
How convenient. The Higgs mass keeps creeping up as well.
It is also highly misleading to credit high energy physics of the early 20th century with the development of semiconductor technology. This field owed very little to high energy research of any kind. Basic quantum mechanics was done to solve problems of atomic physics and thermodynamics (i.e. problems that even chemists would have recognized at the time), and then very quickly (even by Einstein) applied to solid state problems. The people who did cosmic ray (high-energy) research went nowhere.
Basically, the energies probed by these accelerators explore degrees of freedom that are frozen out at room temperature. This physics may have had important practical applications if we were living three seconds after the big bang, but now, a few billion years later, things have cooled down to pretty low energies. That's why we have to spend billions of dollars to recreate high-energy conditions again. Don't fool yourself that this has any future practical impact.
Well, actually, there's no harm in fooling yourself. Just don't try to fool others.
Hmmm. Very interesting.
Still, although I've only read the paper for maybe 10 minutes, it's not reassuring to find that the explanation depends on understanding:
"In other words, the information about theta, though present in Q2, is not detectable by measurements on Q2 alone."
I have a feeling I'm going to have a hard time understanding what he means by such "locally inaccessible information."
Thanks for the pointer.
Look carefully
1) rental
2) lease
3) lending
Anything else?
You are right, of course, but you've simply wrapped all the strangeness up into a vaguely definable "collapse" of the wavefunction. Which I feel favors the latter statement.
This collapse can't really be treated rigorously, because the Schroedinger equation that evolves the wavefunction either has a simple Hamiltonian (the system) which causes linear time evolution (i.e. can't collapse, just rotate in state space), or includes a coupling to a vaguely defined "macroscopic" system which is not in a coherent quantum state. The interaction terms are what give rise to the "collapse" of the components that refer to the microscopic system.
Unfortunately, there is no way to really figure out physically where the incoherence of the big system came from. The incoherence is really more a statement either about ignorance of the true quantum state, which is a cop-out, because then you've forced a collapse on a state that is actually not going to collapse, or about the limitations of being able to set up a macroscopic system in a pure state, because you are at finite temperature, and don't have 10^100 years or whatever to prepare the system carefully enough to resolve the quantum levels of the system. I find this thermodynamic argument persuasive (i.e. it is really what happens), but still philosophically unsatisfying (i.e. it really doesn't physically explain where the thermal disorder comes from, if the universe as a whole is a quantum mechanical system.)
My personal opinion is that there isn't really any great philosophy that can be discovered by thinking about this much harder.
It doesn't necessarily "change the state" of the second particle. (It can't, since the particles cannot causally interact; the particle's state evolves according to the local environment). However, the results of measurements on the second particle are inter-dependent with the results of the measurements of the first particle, even though the acts of measurement themselves cannot be connected causally (in the sense of special relativity).
The really funky thing is that the *choice* made to determine what kind of measurement to make on the first particle affects the inter-dependence. The idea being that "somehow" the measurement apparatus is communicating its setup to the distant particle, even though it really can't. This is really disturbing, but probably doesn't have any better explanation than "that's just how it is."
Your treatment of lefties is either incomplete or confusing. "Main button would be as large as possible." Operated by the index finger? Then it has to be on both sides of the mouse. Creating two equally large buttons creates the question "which one is really the main button." "Thumb side mounted jog wheel." Two of those, right?
As far as configuring the buttons with software, that's a real hassle, and doesn't change the hardware to be any more comfortable.
For me, this is the key reason to favor one-button mice. Lefties and righties are perfectly equal.
Bill Gates is a lefty, but he learned to use a mouse with his right hand, because "it isn't really that hard." Why should it be any effort at all?