It's "Sanders Theatre": there's no apostrophe, and, alas, "theatre" should be (mis)spelled the pretentious British way—but would you expect anything less from Hahvahd?
I've never regretted learning Emacs, though eventually I switched to XEmacs (mainly because Emacs seemed to have trouble highlighting Python syntax correctly).
My pointing device of choice is an Evoluent VerticalMouse. It doesn't force your wrist to twist, which is a Good Thing.
I'm too poor to afford a good chair (since they typically will run you > $1000 + 1 arm + 1 leg), but get one with good lower-back support.
Why due grammer and speling matter, u say? Its only communicashun that matter's? Well, mistake's make you look un-educated or sloopy, which mite be you're problem, but they make thing's harder to reed, wich makes' them my problem. Personally speeching, its' hard for me to read thing's with bad grammer and speling becuz I do'nt like the over head of haveing to correct other people's idiosyncracy's (or mistake's) on the flie. The more mistake's their are, the harder to reed; the fuer, the beter.
Do the math on spelling and grammar---the only winning move is not to err.
I have on good authority that the Jet Propulsion Laboratory has a huge lead over most competition. They already have autonomous vehicles that can travel at ~15 mph over very rough terrain. Keep your eyes out for the Caltech/JPL team to make some real waves.
It's all about the pictures
on
Snowflake Photos
·
· Score: 5, Interesting
I'm sitting right now one story down from the office of Ken Libbrecht, the guy who wrote the book (and the website). Ken told me that he was writing a book on the physics of snowflakes, and I asked him how he expected to get anyone to buy it. "Pictures," he replied, "lots of pretty pictures!"
The Post article shows how the proverbial "guy on the street" reacts to increasing complexity in computers, and many of his gripes ring true even with techies, but I think that he's missing the big picture. It's true that things aren't getting better very fast in certain key areas, at least from the perspective of the typical end-user: notably, operating systems and office products. Not coincidentally, both of these areas have been dominated by monopolistic products that stifle innovation. But in areas where such dominance is not present (or at least not secure, as in the case of Photoshop or Quicken), innovation has been the rule -- and this includes ease-of-use. Try balancing your checkbook with accounting software from 15 years ago.
Nevertheless, nowadays we are seeing major innovation in OSes (e.g., Linux) and office suites (e.g., OpenOffice), and the experience of the end-user in these cases is improving rapidly. Installing and using Linux in 1997 was like pulling teeth compared to the polished installation and interfaces available today. And, by and large, it's still getting better.
To the extent that the gripes are justified, there is a great market opportunity -- an opportunity that will inevitably be filled. Don't like it? Start a company to fix it!
The comment regarding the small number of "big ideas" in the last five years is a bit misleading. Big ideas, like great athletes or brilliant scientists, stand out more if there is less competition. Today's athletes and scientists are the best in history, but there are many fewer Ruths and Einsteins simply because the competition is so much tougher. (Even Barry Bonds is one among many -- hitting 40 home runs in a season used to be remarkable, but now it's practically ordinary.)
I submit that the apparent lack of big ideas in recent times is instead cause for optimism: there are so many big ideas that they all seem to be small. The Internet, cell phones, genome sequencing, nanotechnology, Linux, and George Foreman's Lean Mean Fat Reducing Grilling Machine -- what a great time to be alive!
It might interest some to know that physicists are thinking a lot about grid computing, especially those who use computation heavily, such as numerical relativists and fluid dynamicists. An interesting article appeared last year in Physics Today. Let's hope that the academic community's tradition of openness takes root in the Grid.
Gordon Moore (a Caltech PhD, thank you very much) originally formulated his now-famous law in terms of the time it took to double the number of transistors on an integrated circuit. In that strict sense, Moore's Law is certainly doomed, based on simple physical constraints.
On the other hand, it turns out that the general phenomenon of exponential growth in computation goes back at least a hundred years, and one can make a plausible case that it extends through the entire history of life on Earth. This "generalized Moore's Law" is much more robust than the transistor version.
Yes, that's a great idea. So good, in fact, that several spam companies currently do this (though mainly with teenagers and young adults, not middleschoolers). It's a strange situation -- computers using humans to augment their intelligence.
According to the main Eiffel website, a major aspect of Eiffel is EiffelStudio, their "more than just an IDE" that really makes everything go. They imply that this product is necessary to reap the major benefits of developing in Eiffel, but unfortunately it is quite pricey (not to mention proprietary): the Windows or Linux version will run you $4799. That price, and hitching your wagon to a proprietary star, are major barriers to wider acceptance.
If anyone strongly believes that learning Eiffel is worth the trouble even without a good free (as in speech) IDE, please let me know.
I've used both CWEB and noweb, the latter for a large scientific computing project involving (among other things) a large number of tensor operations. While I've thus found the TeX math typesetting features invaluable, literate programming has some serious drawbacks.
The most common problem for me has been the function/code chunk dichotomy. You might have a code chunk like "Set initial conditions" and only later realize that your chunk is too long and you need a function: set_initial_conditions(). Literate programming makes it so easy to write chunks of code without wrapping them in functions that your code ends up with too many chunks. If you do take the time to make functions then you vitiate much of the advantage of your literate programming chunks, since you end up just deleting the chunks and replacing them with descriptive function names.
Another serious problem is that it is very difficult to invert a literate program into human-readable source code; i.e., if you decide to junk CWEB and go back to C source and header files, you are in big trouble, since the machine-readable source code is horrendous -- not to mention stripped of all comments! So you really make a huge commitment if you decide to go the literate route.
Having used lit. prog. for several small projects and one big project I appreciate some of its advantages, but on balance I think that well-documented standard code is better. The only thing I really miss in standard coding is TeX math typesetting, but this is easy to rectify. I just wrote a simple program to convert a regular source file into LaTeX. I use a Qt-style//! or/*! */ comment and then some TeX formatting in my source code and strip it out later to make my documentation.
einstein.cpp ... /*! Einstein's equation
is $G^{\alpha\beta} = 8\pi T^{\alpha\beta}$. */ for (int i = 0; i != 4; ++i)
for (int j = 0; j != 4; ++j)
G[i][j] = 8*pi*T[i][j];
...
The commands % simple_doc einstein.cpp > einstein.tex % latex einstein then produce a typeset version, with C++ code in typewriter font and the tensor equation in beautiful TeX math fonts.
Lit. prog. might be good for some large, mainly single-author projects such as TeX or Mathematica, but it adds a layer of considerable complexity to your code base, forcing everyone who uses it to learn your system. It will also never make good programmers out of bad ones, and in some ways actually encourages sloppy code by making it easy to write chunks of code without good modular design. As a result, after my current project I'll probably not use a literate programming system again.
Slashdot Mirror
It's "Sanders Theatre": there's no apostrophe, and, alas, "theatre" should be (mis)spelled the pretentious British way—but would you expect anything less from Hahvahd?
Michael Hartl '96
I've never regretted learning Emacs, though eventually I switched to XEmacs (mainly because Emacs seemed to have trouble highlighting Python syntax correctly).
My pointing device of choice is an Evoluent VerticalMouse. It doesn't force your wrist to twist, which is a Good Thing.
I'm too poor to afford a good chair (since they typically will run you > $1000 + 1 arm + 1 leg), but get one with good lower-back support.
-Michael
Why due grammer and speling matter, u say? Its only communicashun that matter's? Well, mistake's make you look un-educated or sloopy, which mite be you're problem, but they make thing's harder to reed, wich makes' them my problem. Personally speeching, its' hard for me to read thing's with bad grammer and speling becuz I do'nt like the over head of haveing to correct other people's idiosyncracy's (or mistake's) on the flie. The more mistake's their are, the harder to reed; the fuer, the beter.
Do the math on spelling and grammar---the only winning move is not to err.
I have on good authority that the Jet Propulsion Laboratory has a huge lead over most competition. They already have autonomous vehicles that can travel at ~15 mph over very rough terrain. Keep your eyes out for the Caltech/JPL team to make some real waves.
I'm sitting right now one story down from the office of Ken Libbrecht, the guy who wrote the book (and the website). Ken told me that he was writing a book on the physics of snowflakes, and I asked him how he expected to get anyone to buy it. "Pictures," he replied, "lots of pretty pictures!"
Looks like he was right!
Nevertheless, nowadays we are seeing major innovation in OSes (e.g., Linux) and office suites (e.g., OpenOffice), and the experience of the end-user in these cases is improving rapidly. Installing and using Linux in 1997 was like pulling teeth compared to the polished installation and interfaces available today. And, by and large, it's still getting better.
To the extent that the gripes are justified, there is a great market opportunity -- an opportunity that will inevitably be filled. Don't like it? Start a company to fix it!
I submit that the apparent lack of big ideas in recent times is instead cause for optimism: there are so many big ideas that they all seem to be small. The Internet, cell phones, genome sequencing, nanotechnology, Linux, and George Foreman's Lean Mean Fat Reducing Grilling Machine -- what a great time to be alive!
It might interest some to know that physicists are thinking a lot about grid computing, especially those who use computation heavily, such as numerical relativists and fluid dynamicists. An interesting article appeared last year in Physics Today. Let's hope that the academic community's tradition of openness takes root in the Grid.
On the other hand, it turns out that the general phenomenon of exponential growth in computation goes back at least a hundred years, and one can make a plausible case that it extends through the entire history of life on Earth. This "generalized Moore's Law" is much more robust than the transistor version.
Don't give up hope on that 1THz laptop just yet.
Yes, that's a great idea. So good, in fact, that several spam companies currently do this (though mainly with teenagers and young adults, not middleschoolers). It's a strange situation -- computers using humans to augment their intelligence.
The IDE is free only for non-commercial use...
According to the main Eiffel website, a major aspect of Eiffel is EiffelStudio, their "more than just an IDE" that really makes everything go. They imply that this product is necessary to reap the major benefits of developing in Eiffel, but unfortunately it is quite pricey (not to mention proprietary): the Windows or Linux version will run you $4799. That price, and hitching your wagon to a proprietary star, are major barriers to wider acceptance.
If anyone strongly believes that learning Eiffel is worth the trouble even without a good free (as in speech) IDE, please let me know.
I've used both CWEB and noweb, the latter for a large scientific computing project involving (among other things) a large number of tensor operations. While I've thus found the TeX math typesetting features invaluable, literate programming has some serious drawbacks.
//! or /*! */ comment and then some TeX formatting in my source code and strip it out later to make my documentation.
...
/*! Einstein's equation
The most common problem for me has been the function/code chunk dichotomy. You might have a code chunk like "Set initial conditions" and only later realize that your chunk is too long and you need a function: set_initial_conditions(). Literate programming makes it so easy to write chunks of code without wrapping them in functions that your code ends up with too many chunks. If you do take the time to make functions then you vitiate much of the advantage of your literate programming chunks, since you end up just deleting the chunks and replacing them with descriptive function names.
Another serious problem is that it is very difficult to invert a literate program into human-readable source code; i.e., if you decide to junk CWEB and go back to C source and header files, you are in big trouble, since the machine-readable source code is horrendous -- not to mention stripped of all comments! So you really make a huge commitment if you decide to go the literate route.
Having used lit. prog. for several small projects and one big project I appreciate some of its advantages, but on balance I think that well-documented standard code is better. The only thing I really miss in standard coding is TeX math typesetting, but this is easy to rectify. I just wrote a simple program to convert a regular source file into LaTeX. I use a Qt-style
einstein.cpp
is $G^{\alpha\beta} = 8\pi T^{\alpha\beta}$.
*/
for (int i = 0; i != 4; ++i)
for (int j = 0; j != 4; ++j)
G[i][j] = 8*pi*T[i][j];
...
The commands
% simple_doc einstein.cpp > einstein.tex
% latex einstein
then produce a typeset version, with C++ code in typewriter font and the tensor equation in beautiful TeX math fonts.
Lit. prog. might be good for some large, mainly single-author projects such as TeX or Mathematica, but it adds a layer of considerable complexity to your code base, forcing everyone who uses it to learn your system. It will also never make good programmers out of bad ones, and in some ways actually encourages sloppy code by making it easy to write chunks of code without good modular design. As a result, after my current project I'll probably not use a literate programming system again.
-Michael