The three20 code has shuffled around a lot in the last 8 months or so, but if you look at the change log here http://github.com/facebook/three20/blob/master/CHANGES#L93 you can see that the maintainer, Jeff (who was a college student at the time and has worked his butt off on three20) is thanking a 3rd party for contributing that code.
There's attribution for other code in three20, so I think it's safe to say that Jeff didn't know.
It's also possible that there was simply a miscommunication somewhere along the chain. I wouldn't assume this is anyone being evil or devious until we hear the full story, and I expect the lack of attribution will be fixed quickly.
I was there two years ago, and it was easily the best conference I've attended. Can't recommend it enough.
What's the general atmosphere of the event?
It's intense (lots of content), and no-nonsense. Every speaker had something valuable to say, and they didn't talk down to the audience at all.
I found the day motivating, especially DHH's talk and just chatting with my peers. With the exception of one person, everyone I met was a hacker and was working on something.
Is it similar to other conferences you've attended?
Not really, one big difference: the overall quality of the attendees. I'm a shy person, but there were so many people talking about writing code (vs. big idea people) that I felt like I fit right in.
Is it simply a day-long sales pitch for YC?
The only real pitch-man the year I attended was Jeff Bezos, his talk was a pitch for AWS. However, he was so impressive during the Q&A that I can forgive him.
There's a new api for shake gestures in 3.0, your firstResponder needs to implement motion[Began|Cancelled|Ended]:withEvent. Works fine in the simulator.
Great story, and also gave me a flash of insight: when considering people to work with, "Would I plan a bank heist with this person?" isn't a half bad question to ask. It implies complete trust both in the person and their ability to perform.
(Or maybe I'm just goofy...when I can't put my finger on what's causing me to hesitate about a person or situation, off-the-wall questions/scenarios usually help me figure out what's really bothering me.)
That he gave Javascript another chance says more about him than his dismissal of it four years ago.
However: The Python community is the frostiest on the planet.
They're complete kneebiting buttheads to the last man.
I try hard not to conflate the merits of a programming language with its "community" (although sometimes that's damned hard to do), and it's made me a happier programmer.
(That said, I don't think I'd characterize the Python community as frosty or buttheads, either today or in 2004.)
actually there are two things about python, which kind of backs yegge's opinion:
1. there is "the only true way" to indent your code;
2. type ctrl-d to exit; :D
> I try hard not to conflate the merits of a programming language with its "community"
Why? The merits of a programming language in today's world boil down to the quality and support of libraries and frameworks, which basically means "the community."
I agree that it is a bug to use Symbol#to_proc or Object#returning in merb, however I suggest that neither of these things are "clever."
Instead, I note that neither of these things are part of the standard library today. Which means, you must open the Object or Symbol classes to implement them. Nothing wrong with that in your code, but when you do so in a framework like merb (or Rails!), everyone using your framework gets your little patches in their namespace as well.
My feeling is that with the way Ruby's global class namespace works today, opening a core class has much more serious consequences when you are writing a framework, gem, or plug-in then when you are writing code that does not have "downstream clients."
Yup. Everything shoved into the dictionary named Smalltalk, including "isA" methods for every subsystem you've written shoved up to Object isn't a big deal for in-house development. When you publish a library or grab one from somewhere, then it becomes a big problem. Then you want namespaces.
So the real-world experience for Smalltalk is that the former is mostly FUD. The latter is a real issue. I suspect that this pretty much applies to the other dynamic languages as well.
I also completely and totally disagree that they're not clever. There is nothing _not_ clever about #returning. It is second only to using inject because you're too lazy to assign to a variable first. Nevermind that every railz0r that does that ignores the fact that they've now assigned N times instead of once.
Clever code, in my mind, is a form of hidden cost. It seems to be what I get paid to deal with (read: remove) the most.
The method was returning :blitz instead of the hash that the method was constructing. I changed it to a returning statement and to my eye it looks much more clear what is going on.
Of course, you could add a "return squid" at the end, or just plain "squid," but somehow that seems less clear, since when you start manufacturing the squid, it isn't obvious what you are doing until you reach the end of the method. Witha returning statement, you know right away.
All in all, I feel good about all constructions in Ruby that use blocks to wrap around the stuff they are doing, like
Foo.transaction do
...
end
But you're younger than I am, so your brain is probably sharper. Maybe you find it easier to just work directly with imperitive-style code. Many people I know prefer it that way. I know I like to simulate Scheme as much as possible, and use expressions instead of assigning local variables as much as possible. It could be laziness on my part.
assignment evaluation to RHS catches everyone once in a while. I'd have gone with the plain `squid` at the end. Maybe even with a `return` if I was feeling chatty. (It took me a long while to get over my anti-return-for-speed-reasons bias... I'm still working on it sometimes.)
Besides, I'm not that much younger than you. :P
I think it is mostly that you went the lispy route while I took the smalltalk route.
ETA:
actually... I'll go one step further...
`returning` violates "Do the Simplest Thing That Could Possibly Work" flat out without giving you anything in return.
"`returning` violates "Do the Simplest Thing That Could Possibly Work" flat out without giving you anything in return."
We agree on the maxim while disagreeing with how to apply it. For me, "returning" is simpler because it seems to involve fewer moving parts: you don't have to remember to write 'squid' at the end and you get a local variable that is scoped only to the block where it is needed.
To you, it is a gross and needlessly complicated way to write begin; squid = ...; squid; end. I can see how you would feel that way without feeling that way myself.
I'm curious about the aversion to Symbol#to_proc. If you see [...].map(&:name) and think of it as an abbreviation for { |element| element.name }, there isn't much to like.
But coming from Smalltalk, does your brain ever click over and make you think of [...].map(&:name) as meaning "map the message :name over this array"?
I ask because when I think of languages like Smalltalk and Ruby, I go along with Alan kay and thenk of them as being message-oriented rather than object-oriented. Symbol#to_proc seems to fit that somehow in my brain. I dunno how to explain it any other way, it really feels less like an abbreviation to save some characters and more like getting closer to what I am trying to say...
Jack Sheridan's talk at startup school (http://omnisio.com/startupschool08/jack-sheridan, a good talk that's not a sales pitch) was an eye-opener for me -- I've become much more disciplined about simply documenting agreements.
Worth reading for some context.