That's being a little unfair. *I* meant it to mean, people who write code in-house, for domain-specific purposes. I suspect that the vast majority of code being written on a daily basis is this kind of code. Stuff that it meant to run a business, not necessarily for public consumption.
Those people just want languages that run well with a standard feature set, and bonus if the language encourages maintainability.
My favorite part about the post is that he points to C# as an example of a "good" language, as if C# and Java were not essentially the same language. The JVM actually isn't all that bad-- it's mature, bug-free, and reasonably fast. But that's beside the point-- the JVM is like x86. Nobody* cares about the instruction set; they care about language features, and whether those features work quickly. And both the Java VM and Microsoft's.NET runtime have numerous options: IronRuby for.NET and JRuby for JVM, IronPython for.NET and Jython for JVM, Clojure, F#, yadda, yadda.
Reinventing the VM is a waste of time. And there are tons of languages to choose from for those VMs. So I don't quite see the point of this. The slides appear to be slashdotted, and just from the post's talking points... yawn.
* "nobody" here should be read as "very few", i.e., mostly people who write JIT compilers and not people who write enterprise code.
As someone who just finished writing a paper (minutes ago) for his graduate empirical methods course, I beg to differ. You can argue that too few CS papers which should be empirical actually are. Fair enough. But there are plenty of areas where good empirical research is being done. Any time the relationship between independent and dependent variables is not known, science is a good place to start. If you haven't come across one of these papers yet, I suggest that you are simply not reading the literature.
CS started as a branch of mathematics, and so there is a natural tendency not to be 'scientific' among many sub-disciplines, particularly in the more theoretical areas. E.g., theory often talks about computational complexity classes that aren't just feasible, they're impossible. But it is still useful to talk about them because it firmly establishes asymptotic bounds on the real stuff. The best CS papers are a kind of dialectic between these two worlds: reason about something deductively, and then use simulation or experimentation to validate your results. Repeat. This is the way physics has operated for nearly two centuries, and CS is finally coming along as well. Given the youth of CS as a field, and thus its relative immaturity, I think people have discovered some pretty amazing things using this method.
Here is an example of a good, empirical CS paper. Here is another really excellent one.
I don't have a problem with averaging over people's reporting of "average ride quality" to come up with a figure like "60% better". Subjective measures are important, particularly if you're an automobile manufacturer. Nobody cares that it is hard to pin down what a 5-star rating on Netflix means, but it is clear that a movie rated 4.5 stars is seen to be better than a movie with 1.2 stars.
What I'm more concerned about is: how did they conduct the study? Did the same people ride in both cars? Could testers tell the difference between the cars, aside from "ride quality"? How were people assigned to the cars? Was there a control group? How many people participated? You don't need a precise unit of ride quality to make a sound statement about what people think about it, but you do need a well-designed study.
I second this, but I am not a biology grad-- I'm a CompSci grad. My undergraduate statistics courses were laughably easy, and in both cases, the profs mysteriously liked to do powerpoints in the DARK. The first class was at 7:30AM. The second at 6:00PM. Not good for retention.
When I came to grad school, I was suddenly thrown into very advanced mathematics. It was assumed that I knew things like graphical models, differential equations, and mathematical logic. I did not. I am now spending my evenings correcting these deficits.
If I had any advice for future grad students, in any science or technology field, it is this: spend a year after your undergrad time just preparing for graduate school. Study advanced math. Take the time to focus on doing well on the GRE. Get some lab experience if you can. Get some practical experience if you can. I put myself through my undergrad while working full time, and my schedule needed to be coordinated with my wife's career, so I did not have the luxury of doing this. But you should. You really should.
That said, even the most prepared grad student will feel unprepared when they get here. I don't know a single person who feels they have adequate knowledge. My friends who were mathematics majors bemoan the fact that their programming skills are so poor (and tell me that I am fortunate to have been a lifelong programmer), but I envy their exposure to things like abstract algebra, advanced statistics, and formal proofs. Having to devise and stick to a plan of self-education is the name of the game. I'm glad that I realized this from the start, but grad school is not easy, and only you can educate yourself.
There's a problem with the study, though: it's a simulation. Simulations aren't in themselves bad-- if your simulation matches reality, then you have good evidence that your model is the way the world works-- but that doesn't appear to be what they did here. They just said "it's a bookkeeping exercise", and performed the simulation. In order for this study to have what we call "external validity", it needs to be matched to epidemiological data. As the article points out, the simulation "did not take into account other potential costs of obesity and smoking, such as lost economic productivity or social costs."
I think these researchers are on the right track, but without actual data, you can't take this researcher's claims at face value.
Sure, but if you ever find yourself in the position of needing to scale things up quickly, you'll be glad you have a little theory in your corner. You'll know which parts of your program you can trivially parallelize, how to keep things moving quickly with hardware constraints, and how to save yourself work by using the more powerful features of your language. Programming is a blend of science and art, and your work will be a lot more fulfilling if you see it that way. This is coming from someone who churned out mundane enterprise/IT code for years, and who now gets to work on really fun things (scientific computing) because of that attitude.
I know you're kidding, but TeX is a seriously great piece of software. LaTeX would not be possible without TeX, which is the de facto standard for typesetting mathematical and scientific papers. And it's easy to use. Have you ever tried using Word or OOo to write anything substantive about math? Forget about it. Learning LaTeX is one of the first items on the agenda of a new grad student in my department. So I tend not to think of TeX as a waste of time on Knuth's part.
People who review Foo for Dummies tend not to read books on theoretical computer science. The self-selection biases the scores, because their scoring criteria are different.
I was an AwesomeBar hater at first, and then I realized that the AwesomeBar allowed me to accumulate huge numbers of bookmarks for which normal navigation was impractical. Now, when I type a word into the address bar, I automatically get the most relevant link in many cases by virtue of the fact that I had bookmarked or visited it before. That is actually awesome!
Re: whether FF4 is worth the upgrade, I'd have to say yes. It is definitely much faster than FF3, which had an annoyingly slow startup time. Pages also render extremely fast. If you're already using FF3, then make the switch. Oh, and Firebug works. I'm happy.
I do not argue that there are religious scientists. Einstein believed strongly in a god, and his religious belief strongly influenced his opinions on quantum mechanics. And as we all know, Einstein was one of the finest scientists in human history.
But you claimed that 'most scientists' were religious, which is a much stronger claim than 'some scientists'. To quote Carl Sagan, "Extraordinary claims require extraordinary evidence". Your claim is a testable hypothesis, so... where's your proof?
When you say that "most people's religious beliefs do not affect their work" is that a FACT or a BELIEF? Because logical discourse relies on FACTS. Also, scientists are not "most people". Speaking as a scientist, we are required to reserve judgement in many cases that non-scientists would find objectionable.
Well, the other obvious answer is that it's not "your data". You may have generated it, but you used their service to do so. I'd say it was always theirs.
If they said to you, "In order to use our service, you need to upload your bank statements", then, well, different story. But that's not what's happening here.
Ignorantia juris non excusat. It may be the case that everybody knows that nobody reads the fine print, but that doesn't mean that the fine print is not there.
Like it or not, Facebook provides a service. There ain't no such thing as a free lunch. If you don't like the exchange, don't participate.
I ripped an equal amount of commit messages per language
That means that PHP users have a lower incidence of swears per commit, i.e., a lower swear frequency. You may now continue your baseless PHP-bashing...
The author seems to intentionally conflate normal differences of opinion as "controversial", and he clearly sees forking as a bad thing. Anybody who's spent time on github knows that forks are a sign that a project is interesting enough to attract eyeballs... Anyway, as a regular (and satisfied) Ubuntu user, this is the first I've heard that I'm not happy...
It's just an example, but I disagree that it is not insightful. For example, the Wright brothers needed a way to calculate lift on certain wing shapes. This is an extremely complicated problem-- currently, supercomputers can only very poorly approximate the real phenomena, especially when flows get turbulent. Of course, the Wright brothers did not have supercomputers. But they did have wind tunnels, and small-scale tests like those done in wind tunnels have a known relationship to the real thing. In a sense, the real problem is at least as hard as the wind tunnel one, therefore, if you can calculate flow over a wing in a wind tunnel, you also have a good idea how it works at full scale. So you can think of your wind tunnel as a kind of analog computer that is computing the real answer that you want. Indeed, this simulation is one of the reasons that the Wright brothers were so successful, and a big reason why, even today, wings shapes are tested in a wind tunnel.
So the idea that the universe "computes" something for us is indeed extremely insightful, and you'll find that this is the fundamental idea behind quantum computation.
But it's still very interesting, because we don't have general solutions to this class of problems. We're not even sure we can have general solutions. To expand on OP's post, the Steiner tree problem is NP-complete, so the fact that ants do this is very interesting. Of course, ants aren't trying to come up with general solutions, but their heuristics may be very, very useful to us nonetheless. For example, 3SAT is NP-complete, but there are apparently SAT solvers in use now with more than a million variables. Wow! Of course, they can't efficiently solve every problem, and in some cases, they may run forever.
It reminds me of a story my computational complexity professor told us. There was a famous Chinese scientist doing a visiting lecture at MIT, and he asked the crowd "What kind of machine can compute all the folds in a crumpled piece of paper?" He then crumpled a piece of paper in front of the crowd, smiled, and said "The Universe can." Sorry, I don't recall the name of the scientist...
You'll be surprised to discover that a great deal of computer science theory is also useful in practice. Take compiler front-ends, essentially the part that parses your written code. Before the 1970's, nearly all of this was done by hand. Now, using formal language theory, almost all of it can be automated, and recent work in grammars can produce ambiguity-free grammars for C, which is full of all kinds of nasty surprises. This means that C compilers become much simpler, produce better output, and are easier to maintain. Solving these problems is not easy, but when you find solutions, their payoffs are huge. Digital computers themselves are the result of some inspired theoretical thinking that happened in the 1920's and 1930's.
I contend that is is nearly impossible to know what R&D will payoff from a practical and economic standpoint. But we know that it often does.
I think you vastly misunderstand security. "Don't put it on the Internet" and "encrypt it" are good rules-of-thumb, but they rely on many assumptions, many of which we only think we understand. For example, P != NP is a fundamental assumption in cryptography, but it is unproven. It appears as if we're probably right, but we do not know for sure. The budget calls for "basic research" in security-- this means that someone who is seeking to understand security from a computational (i.e., mathematical) standpoint can apply. So-- "cybersecurity" doesn't even need to include computers-- it could be a set of general principles for use in any organized system, like the military, or the government, or a company, or e-commerce software. Once you have a good mathematical model for security, you can apply that knowledge generally across many, many fields. You might be looking to develop some principles for preventing leakage of secret information. Ideas like this were developed in the 1970's, but sadly went out of style. We are finding that we need more of this kind of knowledge as it gets easier to leak information.
Slashdot Mirror
That's being a little unfair. *I* meant it to mean, people who write code in-house, for domain-specific purposes. I suspect that the vast majority of code being written on a daily basis is this kind of code. Stuff that it meant to run a business, not necessarily for public consumption.
Those people just want languages that run well with a standard feature set, and bonus if the language encourages maintainability.
You'd think they'd at least port it to MIX for the MIX Conference. False advertising.
That's what .NET is for. Hardware-agnostic malware.
My favorite part about the post is that he points to C# as an example of a "good" language, as if C# and Java were not essentially the same language. The JVM actually isn't all that bad-- it's mature, bug-free, and reasonably fast. But that's beside the point-- the JVM is like x86. Nobody* cares about the instruction set; they care about language features, and whether those features work quickly. And both the Java VM and Microsoft's .NET runtime have numerous options: IronRuby for .NET and JRuby for JVM, IronPython for .NET and Jython for JVM, Clojure, F#, yadda, yadda.
Reinventing the VM is a waste of time. And there are tons of languages to choose from for those VMs. So I don't quite see the point of this. The slides appear to be slashdotted, and just from the post's talking points... yawn.
* "nobody" here should be read as "very few", i.e., mostly people who write JIT compilers and not people who write enterprise code.
As someone who just finished writing a paper (minutes ago) for his graduate empirical methods course, I beg to differ. You can argue that too few CS papers which should be empirical actually are. Fair enough. But there are plenty of areas where good empirical research is being done. Any time the relationship between independent and dependent variables is not known, science is a good place to start. If you haven't come across one of these papers yet, I suggest that you are simply not reading the literature.
CS started as a branch of mathematics, and so there is a natural tendency not to be 'scientific' among many sub-disciplines, particularly in the more theoretical areas. E.g., theory often talks about computational complexity classes that aren't just feasible, they're impossible. But it is still useful to talk about them because it firmly establishes asymptotic bounds on the real stuff. The best CS papers are a kind of dialectic between these two worlds: reason about something deductively, and then use simulation or experimentation to validate your results. Repeat. This is the way physics has operated for nearly two centuries, and CS is finally coming along as well. Given the youth of CS as a field, and thus its relative immaturity, I think people have discovered some pretty amazing things using this method.
Here is an example of a good, empirical CS paper. Here is another really excellent one.
Weird, you buy stuff out of state? Who needs the Internet when you have Massachusetts?
Care to advance an argument instead of an unsubstantiated claim? Call me pedantic.
I don't have a problem with averaging over people's reporting of "average ride quality" to come up with a figure like "60% better". Subjective measures are important, particularly if you're an automobile manufacturer. Nobody cares that it is hard to pin down what a 5-star rating on Netflix means, but it is clear that a movie rated 4.5 stars is seen to be better than a movie with 1.2 stars.
What I'm more concerned about is: how did they conduct the study? Did the same people ride in both cars? Could testers tell the difference between the cars, aside from "ride quality"? How were people assigned to the cars? Was there a control group? How many people participated? You don't need a precise unit of ride quality to make a sound statement about what people think about it, but you do need a well-designed study.
I second this, but I am not a biology grad-- I'm a CompSci grad. My undergraduate statistics courses were laughably easy, and in both cases, the profs mysteriously liked to do powerpoints in the DARK. The first class was at 7:30AM. The second at 6:00PM. Not good for retention.
When I came to grad school, I was suddenly thrown into very advanced mathematics. It was assumed that I knew things like graphical models, differential equations, and mathematical logic. I did not. I am now spending my evenings correcting these deficits.
If I had any advice for future grad students, in any science or technology field, it is this: spend a year after your undergrad time just preparing for graduate school. Study advanced math. Take the time to focus on doing well on the GRE. Get some lab experience if you can. Get some practical experience if you can. I put myself through my undergrad while working full time, and my schedule needed to be coordinated with my wife's career, so I did not have the luxury of doing this. But you should. You really should.
That said, even the most prepared grad student will feel unprepared when they get here. I don't know a single person who feels they have adequate knowledge. My friends who were mathematics majors bemoan the fact that their programming skills are so poor (and tell me that I am fortunate to have been a lifelong programmer), but I envy their exposure to things like abstract algebra, advanced statistics, and formal proofs. Having to devise and stick to a plan of self-education is the name of the game. I'm glad that I realized this from the start, but grad school is not easy, and only you can educate yourself.
There's a problem with the study, though: it's a simulation. Simulations aren't in themselves bad-- if your simulation matches reality, then you have good evidence that your model is the way the world works-- but that doesn't appear to be what they did here. They just said "it's a bookkeeping exercise", and performed the simulation. In order for this study to have what we call "external validity", it needs to be matched to epidemiological data. As the article points out, the simulation "did not take into account other potential costs of obesity and smoking, such as lost economic productivity or social costs."
I think these researchers are on the right track, but without actual data, you can't take this researcher's claims at face value.
Sure, but if you ever find yourself in the position of needing to scale things up quickly, you'll be glad you have a little theory in your corner. You'll know which parts of your program you can trivially parallelize, how to keep things moving quickly with hardware constraints, and how to save yourself work by using the more powerful features of your language. Programming is a blend of science and art, and your work will be a lot more fulfilling if you see it that way. This is coming from someone who churned out mundane enterprise/IT code for years, and who now gets to work on really fun things (scientific computing) because of that attitude.
I know you're kidding, but TeX is a seriously great piece of software. LaTeX would not be possible without TeX, which is the de facto standard for typesetting mathematical and scientific papers. And it's easy to use. Have you ever tried using Word or OOo to write anything substantive about math? Forget about it. Learning LaTeX is one of the first items on the agenda of a new grad student in my department. So I tend not to think of TeX as a waste of time on Knuth's part.
People who review Foo for Dummies tend not to read books on theoretical computer science. The self-selection biases the scores, because their scoring criteria are different.
I was an AwesomeBar hater at first, and then I realized that the AwesomeBar allowed me to accumulate huge numbers of bookmarks for which normal navigation was impractical. Now, when I type a word into the address bar, I automatically get the most relevant link in many cases by virtue of the fact that I had bookmarked or visited it before. That is actually awesome!
Re: whether FF4 is worth the upgrade, I'd have to say yes. It is definitely much faster than FF3, which had an annoyingly slow startup time. Pages also render extremely fast. If you're already using FF3, then make the switch. Oh, and Firebug works. I'm happy.
I do not argue that there are religious scientists. Einstein believed strongly in a god, and his religious belief strongly influenced his opinions on quantum mechanics. And as we all know, Einstein was one of the finest scientists in human history.
But you claimed that 'most scientists' were religious, which is a much stronger claim than 'some scientists'. To quote Carl Sagan, "Extraordinary claims require extraordinary evidence". Your claim is a testable hypothesis, so... where's your proof?
When you say that "most people's religious beliefs do not affect their work" is that a FACT or a BELIEF? Because logical discourse relies on FACTS. Also, scientists are not "most people". Speaking as a scientist, we are required to reserve judgement in many cases that non-scientists would find objectionable.
Well, the other obvious answer is that it's not "your data". You may have generated it, but you used their service to do so. I'd say it was always theirs.
If they said to you, "In order to use our service, you need to upload your bank statements", then, well, different story. But that's not what's happening here.
Ignorantia juris non excusat. It may be the case that everybody knows that nobody reads the fine print, but that doesn't mean that the fine print is not there.
Like it or not, Facebook provides a service. There ain't no such thing as a free lunch. If you don't like the exchange, don't participate.
I ripped an equal amount of commit messages per language
That means that PHP users have a lower incidence of swears per commit, i.e., a lower swear frequency. You may now continue your baseless PHP-bashing...
The author seems to intentionally conflate normal differences of opinion as "controversial", and he clearly sees forking as a bad thing. Anybody who's spent time on github knows that forks are a sign that a project is interesting enough to attract eyeballs... Anyway, as a regular (and satisfied) Ubuntu user, this is the first I've heard that I'm not happy...
It's just an example, but I disagree that it is not insightful. For example, the Wright brothers needed a way to calculate lift on certain wing shapes. This is an extremely complicated problem-- currently, supercomputers can only very poorly approximate the real phenomena, especially when flows get turbulent. Of course, the Wright brothers did not have supercomputers. But they did have wind tunnels, and small-scale tests like those done in wind tunnels have a known relationship to the real thing. In a sense, the real problem is at least as hard as the wind tunnel one, therefore, if you can calculate flow over a wing in a wind tunnel, you also have a good idea how it works at full scale. So you can think of your wind tunnel as a kind of analog computer that is computing the real answer that you want. Indeed, this simulation is one of the reasons that the Wright brothers were so successful, and a big reason why, even today, wings shapes are tested in a wind tunnel.
So the idea that the universe "computes" something for us is indeed extremely insightful, and you'll find that this is the fundamental idea behind quantum computation.
But it's still very interesting, because we don't have general solutions to this class of problems. We're not even sure we can have general solutions. To expand on OP's post, the Steiner tree problem is NP-complete, so the fact that ants do this is very interesting. Of course, ants aren't trying to come up with general solutions, but their heuristics may be very, very useful to us nonetheless. For example, 3SAT is NP-complete, but there are apparently SAT solvers in use now with more than a million variables. Wow! Of course, they can't efficiently solve every problem, and in some cases, they may run forever.
It reminds me of a story my computational complexity professor told us. There was a famous Chinese scientist doing a visiting lecture at MIT, and he asked the crowd "What kind of machine can compute all the folds in a crumpled piece of paper?" He then crumpled a piece of paper in front of the crowd, smiled, and said "The Universe can." Sorry, I don't recall the name of the scientist...
I'm satisfied with having a president who listens to other people, and not just his "gut."
You'll be surprised to discover that a great deal of computer science theory is also useful in practice. Take compiler front-ends, essentially the part that parses your written code. Before the 1970's, nearly all of this was done by hand. Now, using formal language theory, almost all of it can be automated, and recent work in grammars can produce ambiguity-free grammars for C, which is full of all kinds of nasty surprises. This means that C compilers become much simpler, produce better output, and are easier to maintain. Solving these problems is not easy, but when you find solutions, their payoffs are huge. Digital computers themselves are the result of some inspired theoretical thinking that happened in the 1920's and 1930's.
I contend that is is nearly impossible to know what R&D will payoff from a practical and economic standpoint. But we know that it often does.
I think you vastly misunderstand security. "Don't put it on the Internet" and "encrypt it" are good rules-of-thumb, but they rely on many assumptions, many of which we only think we understand. For example, P != NP is a fundamental assumption in cryptography, but it is unproven. It appears as if we're probably right, but we do not know for sure. The budget calls for "basic research" in security-- this means that someone who is seeking to understand security from a computational (i.e., mathematical) standpoint can apply. So-- "cybersecurity" doesn't even need to include computers-- it could be a set of general principles for use in any organized system, like the military, or the government, or a company, or e-commerce software. Once you have a good mathematical model for security, you can apply that knowledge generally across many, many fields. You might be looking to develop some principles for preventing leakage of secret information. Ideas like this were developed in the 1970's, but sadly went out of style. We are finding that we need more of this kind of knowledge as it gets easier to leak information.