He's been a controversial figure in many forums but his emacs lisp tutorial is the best out there. I gave him a donation through Paypal (for approximately the price of an O'Reilly book) and he personally sent me an email thanking me.
I agree with you, but I'm assuming technical questions are asked too. But given several candidates who seem to do well on that portion (which is more of an academic exercise), you have to differentiate them on metrics which you have not (or possibly would have a difficult time) capturing. Hence a set of heuristics which rely on the observation that correlations between practical developer quality (or possibly just the archetype the poster prefers) and seemingly meaningless series of choices exist, you can (hopefully, favorably) bias your decision based on the latter. Choices to speak a lot about the person, especially when it deals with something you work with for such a large fraction of your professional life (e.g., OS, go-to language, sources of information). Sure, you could be selecting mostly mainstream developers and denying potentially stellar candidates, but there is also risk in taking chances with people who fall outside the norm (or what might be the norm for "solid" developers) too. Having said that, I guess I just want to make the statement that while the premise of the post sounds appalling, I'm not entirely against it.
And sorted() and reversed() behave differently (return different object classes) while mylist.sort() and mylist.reverse() do. In that way it's also confusing.
The modify-in-place method does seems more natural when you do want the destructive updating case.
The authors seem very receptive to feedback -- which is encouraging. Maybe I missed if they addressed this, but I wish they'd consider the IDE to be an important part of the language ecosystem. A web REPL is good... but I suspect that (despite Steve Yegge's prediction that the browser is the next IDE) that programmers will expect a serious language/environment to be called interactively through emacs as can R, matlab, and python/ipython (I heard vim can also do this with R?). Or, possibly through an IDE like Rstudio with optional local/server access.
Well explained by chimeracoder. Data-table centric operations are much more natural in R while sequential objects (lists, tuples, and strings) are quickly manipulated in Python (there are more string/regex methods there).
I am a heavy Python user, but when I use Numpy/Scipy I don't feel like I'm using Python much anymore so at that point I either switch to R (or Fortran)... though I'm quite optimistic that at some point the pandas DataFrame can become my default storage structure from which I can parse out R tasks through Rpy, SQLite, HDF5, or possibly Reddis.
matplotlib is very verbose though; I almost prefer Matlab's graphics model... though less so than R's basic and lattice graphics.
But that's the thing - I would argue that NumPy code is not "idiomatic" Python which uses built-in operations/structures, like list comprehensions, tuples, and dictionaries. I had a similar experience during extensive NumPy coding where I thought, why am I not just writing this in Fortran.
I don't hate math but don't quite getting what I can do with this knowledge to develop something new or different from what I would develop without it. Please help with enlightenment?
But isn't there some tacit agreement, or expectation that long-time users and active members will not have to abandon years of investment in a platform -- on a whim of the provider? Of course, the designers are entitled to make their changes... but at the expense of the (supportive) user community? I'm just playing devil's advocate here, but providers would not exist were it not for the demand created by the community. It's true that displeased community members can abandon ship, but they have a right to be angry (in the understanding that they entered a provider-user arrangement upon a "gentleman's agreement" as stated above).
> instead are able to write code that modifies code and generates code as easily as if you were writing the original code in the first place
Is this often done? I know it is conceptually possible with the advantage being that the same functions used to manipulate lists and data are available for this task, but I got the impression that not many people actually do this? For instance...
Thanks -- didn't realize this thread was still alive. So the showstopper is that there is no equivalent to Bayes theorem for fuzzy logic, you're saying. Great clarification.
But good eye on that. ;)