sorted(pairs, key=lambda p: p[1])
sorted(pairs, key=operator.itemgetter(1))
Ruby gives you enough tools to write code clearly with good names if you want to. I think your complaint might be more about the particular style of Ruby a certain programmer wrote than the language itself.
pairs.sort_by(&:last)
As the slideshow illustrated, it's all about having good taste as an author. Knowing your audience and all that. In fact, that might have been a good point to add to his slides--that different coding styles are appropriate for different teams and projects.
times_two = -> (x) {x*2} # Proc (lambda)
times_two = Proc.new {|x| x*2} # Proc
[7, 13, 19, 23, 31].map(×_two)
[7, 13, 19, 23, 31].map(&:to_s)
True, but I have plenty of slides in my presentation without adding more :)
The 'small scope rule' is more of a situation when you can get away with names that are less good, because of the small scope. When I get into discussions about that, everyone agrees with each other, and it distracts from the issue of coming up with good names when the scope isn't tiny.
Also, 'i' for a loop control variable is a trick example: why aren't you using a language that loops over collections without using a loop index?
Looks like that guy followed this guide http://mindprod.com/jgloss/unmainnaming.html
If you can't search for single-letter words in your "simple text editor", why are you using that simple text editor to code? In vi, at least, it's trivial: /\<a\>
I think he was contrasting it to an ide that will automatically find out which as "a"s are references to the same. ("Find usages" in most Java ides I think."
Yes, that's what was being said.
But it won't. In vi (and friends), \< is "beginning of word", and \> is "end of word", so \<a\> will not match the a in "absolute" or "tundra" or "fabulous", but will match the a in "(3+a)" and "a=7". Certainly there are text editors that don't let you express this, but they're so broken as to be basically unusable.
An IDE that is able to keep the various references separate is still more powerful, but the difference is tremendously smaller - particularly if you follow the scoping guidance at the root of this comment thread.
Edited to add: Additionally, if your cursor is already on the word in question, that search is one keystroke. * says "search for the word under the cursor" and incorporates the word boundary markers.
That said, this is also where the scope consideration comes into play. If something is used in 100 different lines, 300 lines apart across 3 files, then of course naming it 'a' is crazy. If something is only in scope over 5 or 10 lines, then you simply restrict your search to those lines (either explicitly with marks, line numbers, or pattern bounds; or implicitly by exiting the search when it gets to a region you don't care about - find-and-replace in vim has a "confirm" option).
So 'i' is fine for a loop control variable with a scope of five lines but totally inadequate for something expressing a larger and longer lived concept.
Ditto for function names and parameters to functions, if the function and the parameters are named properly understanding the function is trivial.
So if you write a chunk of code that exports one or more functions that is where your effort should go, that's the public interface. The reduced scope of the rest of the code should make any naming issues much more limited.
This is also why it is good to assign one person on a team to defining the interfaces between the code. That way you get consistency in naming which is a great thing to have in a codebase.
Anecdote time:
I once worked for a game programming company. One of the programmers there would name all his functions and variables for fruit and vegetables. It was his way of ensuring job security. Guess who got saddled with untangling the salad when he left the company.
cucumber(cherry, strawberry, orange);
Good luck with that...