The first thing I wanted to see as a Smalltalker was how much they've baked Blocks into the libraries. I know Cocoa has always had very long method names, but some of these names are wild:
- #enumerateObjectsUsingBlock: is #do:
- #objectsPassingTest: or #indexesOfObjectsPassingTest: are #select:
The names make perfect sense within the context of the language. Just because you add a new feature to a language doesn't mean you should arbitrarily adopt the naming conventions of its implementation in another language.
The names are silly, and Apple isn't leveraging blocks nearly as much as they could be. The very first thing I did is add an option monad, plus additional collection methods (including the nice and short map and filter) via categories.
My only complaint is that The [[]] messaging syntax gets way too verbose when chaining together sequence comprehensions.
I call it "ctrl+space semantically-aware word completion" and "self-documenting function names."
Nothing unusual in multi-year multi-programmer software.
As much as I like succinct function names, in my experience they don't work when there's more than one hacker involved. A strategy I have followed is to make long names for the top-level, interface-like functions, and succinct ones for all the internals; i.e. put the verbosity where others need to look up code to use it as a library, where "library" is understood as an individual/indepenent component of a larger software project.
The interesting thing from my point of view is that the Delicious Library iPhone app doesn't make Amazon API calls for ISBNs. It synchronized with the desktop version of Delicious Library, which gets its information from the Amazon API. So the headline is pretty carefully written, they're killing mobile apps that use their data.
I refreshed the deactivate page, and it doesn't seem to be completely random, but it also isn't 100% the same every time. It seems to pick between the same 20 or so friends for me.
Another thing that's interesting is that the deactivate option is exactly where it should be, rather than buried many levels deep in menus. I tried to remove my classmates.com account the other day, and it was a mess.
Sure, in brief: Smalltalk because we're most productive in it, Java for some code that particularly needed to be performant, and Ruby because it's better than the other two at interacting with the OS/tying all the pieces together. Obv JS for client-side whiz-bang.
I don't understand why you need obfuscation for this. With customers of this size, you can have them sign a contract that protects your IP. Price in what you think is the risk, and insist on a contract.
This is something to be proud of, and github is great work.
It's not really accurate, though because this lists every user's fork of a gem as a distinct gem. Here's a script I put together to get a different count, which I believe is more of a "real" count.
Forks aren't gem-enabled by default. Meaning, the forker had to go out of their way to indicate there is something different about their gem. Is it possible there isn't unique code on some of these gems? Sure, but I wouldn't discount them outright.
