Most CS programs aren't intended to teach software design principles, except insofar as they're needed for you to get any work done. The focus, at least in the programs I'm familiar with, is on computer science as a science -- something akin to math applied to computers. If you want to learn how to program well, there's Software Engineering for that.
If you have a strong CS background, the National Science Foundation's Research Experience for Undergraduates program is a good bet. Highly competitive, but not impossible to get into if you have good qualifications. Take a look here. Unfortunately, at least 2/3 or so of the deadlines for this summer have already passed, so you'd better hurry to apply for the remaining few.
Barring that, many universities hire summer interns to do research with professors. Get to know some people in the CS department and see if there are any such opportunities.
I'm most familiar with Scheme, so can't comment on Lisp directly, but it's generally considered to only have one data type -- that of "Scheme object" (or "Scheme thing"). As with the parent poster's description of TCL, each object is internally stored with a particular data type, which can be tested with various predicates (like number?), but there's no actual typing system. You can assign anything to anything else, and call any function on any other object, and there will be no static type errors because there are no types. There will be run-time errors if you try to do things like take the first element of something that internally isn't a list, but that's unavoidable in any language (including TCL).
Tcl is a language that has a only one syntax for every kind of operation. It has only one data type, though under the hood it stores data that you use as, say, an integer, appropriately. The 'if' statement, rather than being a special construct, is just another procedure which happens to take code to be evaluated as one of its textual arguments. There are no exceptions to the syntax, which makes it easier to understand.
Congratulations, you just described the features LISP had back in 1956. If you really want to run a language with those features, use Scheme, which is at least a bit cleaner.
The only decent advantage I've seen for pass-by-name is the oft-cited Jensen's device (lets you calculate summations rather elegantly by taking advantage of the way pass-by-name works). On the whole, it leads to a lot of unintuitive behavior, which means a lot of bugs.
It might've made it easier, but SETI's been perennially due for funding cuts whenever money gets tight. When people think "which of the projects we're spending money on isn't really that essential," it's not surprising that "searching for aliens" comes up near the top of the list.
Of the variuos IM services I know of, AIM is the most reliable. Over the past four or so years, there hasn't been a service outage longer than a few minutes (the last major outage of 4-5 hours was five or so years ago, iirc). It occasionally has weird quirks with loading your buddy list from the server, but it's pretty much never actually down. This isn't true of most of its competitors.
You'd have to know more about how the system works to tell. It's very well possible that those songs share some mathematical similarities with other less original hit songs. Statistical methods can find rather deep hidden similarities even in superficially dissimilar things.
Well, CISC makes programming a compiler easier, yes. But you only have to do that once. The idea here is that a RISC chip with a horribly complex compiler is a win over a CISC chip with a simple compiler, because the compiler can do a lot of stuff at compile-time, using a big window (the entire program if necessary), while the CISC chip has to do everything at run-time using a small window (the current instruction plus any lookahead). This makes deep pipelines increasingly slow. Sure, it's a gigantic pain in the ass to properly order instructions for pipelining, but the compiler is in a better position to do this efficiently than the CPU is (and what's more, it only has to do it once, instead of at run-time).
Well, there were never delivery guarantees per se, but there was a lot of work put into the SMTP protocol design so that there was a reasonable expectation that either your email would be delivered, or you'd get notification that it wasn't delivered. And except for spam filtering, this is still usually true -- if your email is not delivered for any reason other than spam filtering, you'll almost always get a bounce message (either from the mailserver on the other end, in the case of invalid accounts/etc., or from your mailserver, in the case of unreachable hosts/etc.).
I'd argue this collateral damage has destroyed the usefulness of email even more than spam has. It's simply an unreliable medium these days -- you never know if your mail got there or not, because it could have been silently dropped with no bounce message sent. Thus whenever I send reasonably-important emails now, I use either the phone or AIM to confirm it was received.
In a head-to-head comparison of SACD/DVD-A versus CD, many people will hear a difference, but this is almost certainly because of the better mastering DVD-A and SACD undergo. Modern CDs are mastered terribly (on purpose), with a high level of dynamic compression so that all tracks sound "loud enough" to grab attention on the radio. The result is a pretty horrible mess. Obviously, since they're targetted at an audiophile audience, DVD-A and SACD aren't subjected to that. However, if you took a properly mastered recording, and pressed SACD/DVD-A and CD from identical source material, then I'd be willing to wager that almost nobody would be able to tell the difference (and on most music, absolutely nobody would be able to).
DVD-A and SACD aren't much better anyway
on
The Future of the CD
·
· Score: 4, Insightful
The supposed quality improvements in SACD and DVD-A are likely not audible by the vast majority of people. In double-blind tests, very few people can tell the difference between ~200kbps VBR mp3s and the original source CD. And the difference between SACD/DVD-A and CD is even less than that. The point being that CD is already overkill -- you can throw out 80% of the information and almost nobody will notice.
And the things they're "better" at aren't really necessary. CDs already have ~44 KHz sample rates, enough to accurately reproduce frequencies up to ~22 KHz. Since most humans drop off hearing around 18-20 KHz, with 21-22 KHz being the absolute max, going to 96 KHz sample rate is certainly not needed (and the added frequency resolution isn't noticeable to anyone either). And as for bits per sample, 16-bit audio already provides enough dynamic range to in good quality represent far more than the vast majority of equipment can reproduce.
There are some pretty good machine learning techniques that can do things like that. Some start with more hints than others, and some work better than others. It's definitely a very open area of research.
I'd also note that if computers can do this, however, it's imposing stronger requirements on them than on humans -- most humans learn a great deal of things from others rather than deducing them on their own from basic rules or first principles, which is in some ways akin to programming a computer with strategies.
It's speculated (by some anyway) that much of human "intelligence," in this example the comparatively excellent middle-game play, is essentially an extremely advanced pattern recognition ability (Kasparov's famous quip that he only analyzes 2-3 moves/second, "but they're the best ones"). Certainly computers have nowhere near this good pattern recognition currently (they have trouble even consistently recognizing faces under different lighting conditions and angles, something humans do effortlessly). However, I see no reason why it is in principle impossible for computer pattern recognition to meet or exceed that of humans, and thus excel at tasks that require it.
I'm aware that there are unsolvable games; more specifically I was questioning the existence of unsolvable-by-a-computer games that are nonetheless solvable by a human. That is, for any given game, the computer should be able to play as well as or better than a human player. For unsolvable games, this simply means emulating the heuristics a human player uses.
I'm not convinced that a human is capable of solving the halting problem in the general case. In a case where the human can trace all possible execution paths, or deduce other things about the program's behavior, it's solvable, but a computer can solve the problem in these cases as well. In short, give me any particular program that a human can solve the halting problem for, and I'd bet you can codify the logic used so that a computer can do so just as well (and given enough samples, code a general computer program with the same power as the human in this domain).
Basically, to prove your point, you'd need to show that humans have some processing power strictly greater than that of a Turing machine, which is a somewhat controversial thesis.
You assume that there is such a thing as an "unsolvable" game. This is not, as far as I know, established. There are certainly things with a near-infinite number of potential solutions, but this is not the same as being unsolvable. Even subjective things (such as producing pleasing music) could theoretically be solvable given enough neurological data (i.e. a computer could use the data on how the human brain interprets music to compose music it knows to be pleasing to at least a certain segment of the population).
The analysis is the same if you want to discuss probability of dying in either event. There is a very good chance that there will be a plane crash (several, in fact) during your lifetime, but a relatively poor chance that you will be on one of the crashed planes. On the other hand, there is a very low likelihood that an asteroid will hit the earth, but if it does, there is a very good chance that you will be killed by it. This is why statistics and probability are very closely related, since the number of people killed in an event affects your probability of being one of those people (the more people killed, the more likely you are to be one of them, all other things being equal).
After Roger and Me, I'm pretty loathe to see anything else by Moore. He seems to like to take pet causes of the left and turn them into a ridiculous circus of a "documentary" reminiscent of MTV's fine programming.
It's pretty hard to actually get a judgment for something like that. In general, they only have to follow the terms they explicitly promised to you in the contract. If changing any service was illegal, it'd be illegal to even do things like raise rates.
Slashdot Mirror
Most CS programs aren't intended to teach software design principles, except insofar as they're needed for you to get any work done. The focus, at least in the programs I'm familiar with, is on computer science as a science -- something akin to math applied to computers. If you want to learn how to program well, there's Software Engineering for that.
Barring that, many universities hire summer interns to do research with professors. Get to know some people in the CS department and see if there are any such opportunities.
I'm most familiar with Scheme, so can't comment on Lisp directly, but it's generally considered to only have one data type -- that of "Scheme object" (or "Scheme thing"). As with the parent poster's description of TCL, each object is internally stored with a particular data type, which can be tested with various predicates (like number?), but there's no actual typing system. You can assign anything to anything else, and call any function on any other object, and there will be no static type errors because there are no types. There will be run-time errors if you try to do things like take the first element of something that internally isn't a list, but that's unavoidable in any language (including TCL).
Tcl is a language that has a only one syntax for every kind of operation. It has only one data type, though under the hood it stores data that you use as, say, an integer, appropriately. The 'if' statement, rather than being a special construct, is just another procedure which happens to take code to be evaluated as one of its textual arguments. There are no exceptions to the syntax, which makes it easier to understand.
Congratulations, you just described the features LISP had back in 1956. If you really want to run a language with those features, use Scheme, which is at least a bit cleaner.
How does pass-by-name make recursion any easier?
The only decent advantage I've seen for pass-by-name is the oft-cited Jensen's device (lets you calculate summations rather elegantly by taking advantage of the way pass-by-name works). On the whole, it leads to a lot of unintuitive behavior, which means a lot of bugs.
It might've made it easier, but SETI's been perennially due for funding cuts whenever money gets tight. When people think "which of the projects we're spending money on isn't really that essential," it's not surprising that "searching for aliens" comes up near the top of the list.
Sure, C's syntax and semantics are elegant compared to, say, FORTRAN77, but come on. It's quite possibly one of the messiest languages out there.
Of the variuos IM services I know of, AIM is the most reliable. Over the past four or so years, there hasn't been a service outage longer than a few minutes (the last major outage of 4-5 hours was five or so years ago, iirc). It occasionally has weird quirks with loading your buddy list from the server, but it's pretty much never actually down. This isn't true of most of its competitors.
You'd have to know more about how the system works to tell. It's very well possible that those songs share some mathematical similarities with other less original hit songs. Statistical methods can find rather deep hidden similarities even in superficially dissimilar things.
Well, CISC makes programming a compiler easier, yes. But you only have to do that once. The idea here is that a RISC chip with a horribly complex compiler is a win over a CISC chip with a simple compiler, because the compiler can do a lot of stuff at compile-time, using a big window (the entire program if necessary), while the CISC chip has to do everything at run-time using a small window (the current instruction plus any lookahead). This makes deep pipelines increasingly slow. Sure, it's a gigantic pain in the ass to properly order instructions for pipelining, but the compiler is in a better position to do this efficiently than the CPU is (and what's more, it only has to do it once, instead of at run-time).
Well, there were never delivery guarantees per se, but there was a lot of work put into the SMTP protocol design so that there was a reasonable expectation that either your email would be delivered, or you'd get notification that it wasn't delivered. And except for spam filtering, this is still usually true -- if your email is not delivered for any reason other than spam filtering, you'll almost always get a bounce message (either from the mailserver on the other end, in the case of invalid accounts/etc., or from your mailserver, in the case of unreachable hosts/etc.).
I'd argue this collateral damage has destroyed the usefulness of email even more than spam has. It's simply an unreliable medium these days -- you never know if your mail got there or not, because it could have been silently dropped with no bounce message sent. Thus whenever I send reasonably-important emails now, I use either the phone or AIM to confirm it was received.
In a head-to-head comparison of SACD/DVD-A versus CD, many people will hear a difference, but this is almost certainly because of the better mastering DVD-A and SACD undergo. Modern CDs are mastered terribly (on purpose), with a high level of dynamic compression so that all tracks sound "loud enough" to grab attention on the radio. The result is a pretty horrible mess. Obviously, since they're targetted at an audiophile audience, DVD-A and SACD aren't subjected to that. However, if you took a properly mastered recording, and pressed SACD/DVD-A and CD from identical source material, then I'd be willing to wager that almost nobody would be able to tell the difference (and on most music, absolutely nobody would be able to).
The supposed quality improvements in SACD and DVD-A are likely not audible by the vast majority of people. In double-blind tests, very few people can tell the difference between ~200kbps VBR mp3s and the original source CD. And the difference between SACD/DVD-A and CD is even less than that. The point being that CD is already overkill -- you can throw out 80% of the information and almost nobody will notice.
And the things they're "better" at aren't really necessary. CDs already have ~44 KHz sample rates, enough to accurately reproduce frequencies up to ~22 KHz. Since most humans drop off hearing around 18-20 KHz, with 21-22 KHz being the absolute max, going to 96 KHz sample rate is certainly not needed (and the added frequency resolution isn't noticeable to anyone either). And as for bits per sample, 16-bit audio already provides enough dynamic range to in good quality represent far more than the vast majority of equipment can reproduce.
The number of people using CSS-compliant browsers is far less than 99%. Just Netscape4 users alone still account for significantly more than 1%.
There are some pretty good machine learning techniques that can do things like that. Some start with more hints than others, and some work better than others. It's definitely a very open area of research.
I'd also note that if computers can do this, however, it's imposing stronger requirements on them than on humans -- most humans learn a great deal of things from others rather than deducing them on their own from basic rules or first principles, which is in some ways akin to programming a computer with strategies.
It's speculated (by some anyway) that much of human "intelligence," in this example the comparatively excellent middle-game play, is essentially an extremely advanced pattern recognition ability (Kasparov's famous quip that he only analyzes 2-3 moves/second, "but they're the best ones"). Certainly computers have nowhere near this good pattern recognition currently (they have trouble even consistently recognizing faces under different lighting conditions and angles, something humans do effortlessly). However, I see no reason why it is in principle impossible for computer pattern recognition to meet or exceed that of humans, and thus excel at tasks that require it.
I'm aware that there are unsolvable games; more specifically I was questioning the existence of unsolvable-by-a-computer games that are nonetheless solvable by a human. That is, for any given game, the computer should be able to play as well as or better than a human player. For unsolvable games, this simply means emulating the heuristics a human player uses.
I'm not convinced that a human is capable of solving the halting problem in the general case. In a case where the human can trace all possible execution paths, or deduce other things about the program's behavior, it's solvable, but a computer can solve the problem in these cases as well. In short, give me any particular program that a human can solve the halting problem for, and I'd bet you can codify the logic used so that a computer can do so just as well (and given enough samples, code a general computer program with the same power as the human in this domain).
Basically, to prove your point, you'd need to show that humans have some processing power strictly greater than that of a Turing machine, which is a somewhat controversial thesis.
You assume that there is such a thing as an "unsolvable" game. This is not, as far as I know, established. There are certainly things with a near-infinite number of potential solutions, but this is not the same as being unsolvable. Even subjective things (such as producing pleasing music) could theoretically be solvable given enough neurological data (i.e. a computer could use the data on how the human brain interprets music to compose music it knows to be pleasing to at least a certain segment of the population).
The analysis is the same if you want to discuss probability of dying in either event. There is a very good chance that there will be a plane crash (several, in fact) during your lifetime, but a relatively poor chance that you will be on one of the crashed planes. On the other hand, there is a very low likelihood that an asteroid will hit the earth, but if it does, there is a very good chance that you will be killed by it. This is why statistics and probability are very closely related, since the number of people killed in an event affects your probability of being one of those people (the more people killed, the more likely you are to be one of them, all other things being equal).
After Roger and Me, I'm pretty loathe to see anything else by Moore. He seems to like to take pet causes of the left and turn them into a ridiculous circus of a "documentary" reminiscent of MTV's fine programming.
It's pretty hard to actually get a judgment for something like that. In general, they only have to follow the terms they explicitly promised to you in the contract. If changing any service was illegal, it'd be illegal to even do things like raise rates.
A constant 56k stream for 24 hours continuously would only add up to a little over half a gigabyte.
Service is now sold as "max of 1 GB/day" for a fixed rate.