When you have 0/0, you hit two "obvious" but contradictory rules in basic algebra:
Rule one: anything multiplied by zero is zero Rule two: anything divided by itself is one
Mathematicians don't know which rule has precedence for 0/0, so there's no way a dumb machine can figure it out, which is why most programing languages just throw an exception if zero is the denominator.
Using R vs Python with Pandas brought home the microlanguage vs libraries debate for me. I'm more experienced and comfortable programing in Python, so generally prefer it. But writing a program to solve the same problem in R or Python, I found the R version would be much faster. On the other hand, the Python version tended to give the correct answer, whereas the R version tended to have weird bugs I couldn't figure out.
As an open source enthusiast, I'd say an unfortunate advantage Python has is its "benevolent dictator" rule for libraries. R (as with Perl, TeX...) has a bewildering number of contributed packages for any given problem, some of which once worked well with old versions, others were never developed properly... so users are left with the frustration of finding something that works.
Python, on the other hand, comes with "batteries included" with a few external libraries like Pandas that are well supported. So unless speed is a big deal, I'd advise Python.
As someone who is always trying to get other people to share my love of MooCs (I've completed about 30) with mixed success, I've found they shine at "puzzle oriented" subjects, but not so well on humanities.
A lot of my enjoyment of MooCs comes from how sophisticated their grading technology is. One of my favorites was Software as a Service, initially offered on Coursera and then moved to edx. The grader didn't simply mark your program as right or wrong, but turned it into a challenging game by forcing you to get the final few marks by tweeking the code for subtle tests. This drove the advantages of test driven development home in a practical way. Learning software development this way turns it into a fun challenge like doing a crossword, sodoku or some other kind of puzzle. Nobody enjoys watching someone scribble maths on a blackboard, while everyone enjoys solving puzzles -- and that's what makes MooCs so much better at teaching "puzzle oriented" subjects.
The MooCs I've enjoyed least have involved peer reviewed essays. The early ones I did forced students to explain the reasoning for their marks, so if you got a bad mark at least you got a clue on how competent your "peer" was. But later ones did not include a feature to leaves comment, and I now tend to ditch those since it's infuriating to get a bad mark for hard work without any explanation.
The quality of MooCs varies considerably. The first one I did -- Stanford's Introduction to Database course -- was fantastic and has kept me enrolling for more. Unfortunately, some are duds and people who start with those don't become MooC addicts.
My experience at this comes from being a MooC addict where some of the courses are in Python, others in R, and others in Matlab or its GNU counterpart Octave.
Of these Python is my favorite since it's the language I'm most familiar with. Furthermore, you can "bolt" R to Python with the Pandas library, and you can "bolt" Matlab/Octave with the Numpy & Scipy libraries.
A big drawback, however, is speed. The big advantage of domain specific mini-languages over "kitchen sink" languages was brought home to me by writing a Python script to simulate the popular (in statistics courses) Monty Hall problem and the same script in R. While my Python script took several seconds to simulate a couple of thousand Monty Hall game turns, the R script would give the percentage for millions the instant I hit the enter key.
More complicated problems ended up with weird bugs in R scripts I couldn't figure out, whereas (because of my better familiarity with Python's "mutable list" problems) I tended to get correct -- albeit slower -- answers from my Python programs.
Re Octave: whereas R has overtaken commercial versions of S, I've written off Octave as a lame "freeware" version of Matlab -- lots of features are missing, the documentation is frustrating (it seems to only be used by universities, so "gurus" on stackoverflow etc automatically assume any question is some student trying to cheat at homeworkd) so I'm not a fan. But if I knew Octave as well as Python, I might like it.
R, on the other hand, has an obvious speed advantages for the problems it's aimed at, and a probably a better selection of specialist libraries for statistical problems. But it's full of strange quirks for non specialists.
The full quote from the article that Miguel "believes that a large portion of the software developers that could have taken Linux to greater heights defected to other platforms, including not only Apple OS X but — more importantly — the web" is very true for me. I used to program Gnome apps but now focus entirely on web app development.
The modern trend is summed up nicely in a lecture by John Ousterhout of TCL fame on web application development at Stanford found at http://openclassroom.stanford.edu/MainFolder/CoursePage.php?course=WebApplications. The relevant one here is his first video in which he draws a tombstone on the blackboard and writes "Download Install Binaries RIP" in it and predicts the only applications anyone will be installing this way in the near future will be browsers.
My money is on Prof Ousterhout — Google's documents have already replaced MS Office for me (I work for a company where getting Excel installed on my PC was impossible, but that's no problem now since Google provides a spreadsheet via my browser which is far superior since the files it creates are more securely stored and shareable).
Now all the hassles with different operating systems and GUIs fall away for application developers who can use browsers as their universal canvas. For us Unix old timers, this might sound like an Emacs future (and recal Emacs did spawn Mosaic, the father of Netscape and grandad of Firefox), but it's now reality.
Slashdot Mirror
Interesting case I hadn't thought of. I'd vote it up, but don't seem to have enough slashdot street cred.
Let me rewrite that as:
Rule 1: 0*X (where X = 1/0)
Rule 2: X/X (where X = 0)
I've had this argument often with APL fans who don't get that as obvious as 0/0 = 1 may sound, it's not mathematically sound.
When you have 0/0, you hit two "obvious" but contradictory rules in basic algebra:
Rule one: anything multiplied by zero is zero
Rule two: anything divided by itself is one
Mathematicians don't know which rule has precedence for 0/0, so there's no way a dumb machine can figure it out, which is why most programing languages just throw an exception if zero is the denominator.
Using R vs Python with Pandas brought home the microlanguage vs libraries debate for me. I'm more experienced and comfortable programing in Python, so generally prefer it. But writing a program to solve the same problem in R or Python, I found the R version would be much faster. On the other hand, the Python version tended to give the correct answer, whereas the R version tended to have weird bugs I couldn't figure out.
As an open source enthusiast, I'd say an unfortunate advantage Python has is its "benevolent dictator" rule for libraries. R (as with Perl, TeX...) has a bewildering number of contributed packages for any given problem, some of which once worked well with old versions, others were never developed properly... so users are left with the frustration of finding something that works.
Python, on the other hand, comes with "batteries included" with a few external libraries like Pandas that are well supported. So unless speed is a big deal, I'd advise Python.
As someone who is always trying to get other people to share my love of MooCs (I've completed about 30) with mixed success, I've found they shine at "puzzle oriented" subjects, but not so well on humanities.
A lot of my enjoyment of MooCs comes from how sophisticated their grading technology is. One of my favorites was Software as a Service, initially offered on Coursera and then moved to edx. The grader didn't simply mark your program as right or wrong, but turned it into a challenging game by forcing you to get the final few marks by tweeking the code for subtle tests. This drove the advantages of test driven development home in a practical way. Learning software development this way turns it into a fun challenge like doing a crossword, sodoku or some other kind of puzzle. Nobody enjoys watching someone scribble maths on a blackboard, while everyone enjoys solving puzzles -- and that's what makes MooCs so much better at teaching "puzzle oriented" subjects.
The MooCs I've enjoyed least have involved peer reviewed essays. The early ones I did forced students to explain the reasoning for their marks, so if you got a bad mark at least you got a clue on how competent your "peer" was. But later ones did not include a feature to leaves comment, and I now tend to ditch those since it's infuriating to get a bad mark for hard work without any explanation.
The quality of MooCs varies considerably. The first one I did -- Stanford's Introduction to Database course -- was fantastic and has kept me enrolling for more. Unfortunately, some are duds and people who start with those don't become MooC addicts.
My experience at this comes from being a MooC addict where some of the courses are in Python, others in R, and others in Matlab or its GNU counterpart Octave.
Of these Python is my favorite since it's the language I'm most familiar with. Furthermore, you can "bolt" R to Python with the Pandas library, and you can "bolt" Matlab/Octave with the Numpy & Scipy libraries.
A big drawback, however, is speed. The big advantage of domain specific mini-languages over "kitchen sink" languages was brought home to me by writing a Python script to simulate the popular (in statistics courses) Monty Hall problem and the same script in R. While my Python script took several seconds to simulate a couple of thousand Monty Hall game turns, the R script would give the percentage for millions the instant I hit the enter key.
More complicated problems ended up with weird bugs in R scripts I couldn't figure out, whereas (because of my better familiarity with Python's "mutable list" problems) I tended to get correct -- albeit slower -- answers from my Python programs.
Re Octave: whereas R has overtaken commercial versions of S, I've written off Octave as a lame "freeware" version of Matlab -- lots of features are missing, the documentation is frustrating (it seems to only be used by universities, so "gurus" on stackoverflow etc automatically assume any question is some student trying to cheat at homeworkd) so I'm not a fan. But if I knew Octave as well as Python, I might like it.
R, on the other hand, has an obvious speed advantages for the problems it's aimed at, and a probably a better selection of specialist libraries for statistical problems. But it's full of strange quirks for non specialists.
The full quote from the article that Miguel "believes that a large portion of the software developers that could have taken Linux to greater heights defected to other platforms, including not only Apple OS X but — more importantly — the web" is very true for me. I used to program Gnome apps but now focus entirely on web app development.
The modern trend is summed up nicely in a lecture by John Ousterhout of TCL fame on web application development at Stanford found at http://openclassroom.stanford.edu/MainFolder/CoursePage.php?course=WebApplications. The relevant one here is his first video in which he draws a tombstone on the blackboard and writes "Download Install Binaries RIP" in it and predicts the only applications anyone will be installing this way in the near future will be browsers.
My money is on Prof Ousterhout — Google's documents have already replaced MS Office for me (I work for a company where getting Excel installed on my PC was impossible, but that's no problem now since Google provides a spreadsheet via my browser which is far superior since the files it creates are more securely stored and shareable).
Now all the hassles with different operating systems and GUIs fall away for application developers who can use browsers as their universal canvas. For us Unix old timers, this might sound like an Emacs future (and recal Emacs did spawn Mosaic, the father of Netscape and grandad of Firefox), but it's now reality.