jbrechtel

This talk by Hans Rosling makes a pretty reasonable case for decoupling the notion of religion and birth rates.

http://www.ted.com/talks/lang/en/hans_rosling_religions_and_...

I didn't mean to imply that video game programmers were stupid... :)

I was saying it seems more likely to me that any random developer making a stupid mistake like this seems more likely than a company having real motivation to create this kind of security hole.

I suppose, alternatively, this could have been an individual developer's intent. An exploit like this would get a pretty penny on the exploit market, I'd think.

Since we have no additional evidence to select between the two options, do you really think that malice is simpler than stupidity?

None of those things compile to Objective-C. They each provide a runtime for C#, Javascript and Ruby respectively with bindings to the underlying Objective-C apis. And they each do it in a different way, with different levels of layers between the normal Cocoa APIs.

What 'language infrastructure' are you talking about?

I can understand this reasoning, but is it really the case? In practice does anyone actually stick to HTC or Motorola because of their skins?

I know that the feedback I usually hear has a huge selection bias in this regard (almost all techies) which is why I'm asking the question.

Even considering the selection biased, I'd be surprised if people preferred these skins. I think that people who are aware of these skins, and the options out there, probably don't like them. If they're not aware of them then they can't prefer them, right?

Does it have to be blind or random though?

A path finding algorithm is clearly teleological, but also has false starts. That doesn't make it 'blind' or 'random'.

Definitely agreed about the lack of evidence for teleology among evolution, but I don't think false starts, extinct species, etc... are counter evidence to teleology really. They'd just be evidence of an imperfect process attempting to reach that goal.

Having a destination in mind doesn't mean you know exactly how to get there, right?

Wasn't there? There were a number of functions he didn't port. He ended up with a subset of OpenGL 1.3. Maybe that subset wasn't worth the effort?

Depends on what it is you're testing. You could be testing a vhost setup, in which case different ports or paths wouldn't suffice for testing. More specifically you could be an application's behavior when given different vhosts. Make sense?

Nice. I didn't realize you could parameterize the conditionals so I did this (bumps into walls):

while (true) do if(wall ahead) then turn left else move forward turn left if(wall ahead) turn right

Scala (and likely Ruby) have a very specific reason for doing this.

http://en.wikipedia.org/wiki/Uniform_access_principle

It does put more onus on the API implementer to be careful about hiding non-trivial work, like you say.

I hear this argument a lot but I just don't get it.

In almost every case the time spent doing those things (queueing for gas or fixing someone's PC) could, or better yet, would not have otherwise been spent making >$30/hour.

Really? The Twitter app on Android is a webview as well and it also sucks.

What are you looking for with an Android REPL? Asking because this is something I might be interested in building. Feel free to take the conversation to email (@gmail) or twitter (@jbrechtel) if you'd rather limit the off-topic discussion.

I wholeheartedly disagree. There are bad programming languages. Brainfuck is a good example. I don't mean that as a joke, but only as proof that programming languages can be objectively bad. As an extension of that I'd say that languages can be bad because of their constituent parts (syntax, semantics, constructs, features or lack of, etc..).

Some languages have constituent parts that I'd say are objectively bad. I'll argue all day that Objective-C's handling of nil is stupid beyond belief. Nil/Null itself is bad enough...

You could achieve the same sharing you can with C# via MonoTouch (iOS) and MonoDroid (Android).

"I know, I know- you need to go with the native languages for the best experience."

What about doing this improves the experience?

Seems like without SSL there are still several scenarios where a webservice over HTTPS is more appropriate?

Are you saying you see no evolutionary purpose for consciousness? This is a (very short) interesting book on the topic: http://www.amazon.com/Seeing-Red-Consciousness-Behavior-Init...

Why would sugared destructuring not make sense in C#? Or first class events and delegates?

Crazy. I could have (honestly) written this exact same post, timeline and all.

Standups are good for both surfacing as well as identifying problems (e.g. things that don't appear to be problems).

Standups aside, sure, ssync information is good. However, it's not nearly as rich as face to face communication.

I'm not sure why you say meetings should be for solving problems. The majority of my meetings are about sharing information and planning. I solve problems at my desk.

Arbitrary schedule and bad habits about wasting time on stupid problems aside, I'd agree that a standup for a well functioning, co-located dev team is largely going to be redundant.

The most value I've found in standups are when you have a cross functional team that can communicate status on different things to everyone all at once. BAs, QAs, devs, IM/PM, and product owners aren't all going to stay up to date with each other naturally on most teams.

Of course, if teams are working in very long iterations with out-of-cycle QA then each functional aspect of the team staying up to date with each other on a daily basis yields less value. Such a setup tends to bring about other problems in many scenarios though.

In the end it's all about context. To say a daily standup is a stupid practice without context (implying in any context) is a bit too broad of a statement IMHO.

I'm not sure I get what your point is? Sounds like they did a good job estimating but would give in to pressure to arbitrarily change their estimates? How does that conflict with aharrison's point that estimates/plans are poor in most fields largely because of the way we plan?

Daniel Kahneman talks about the planning fallacy as well as many other biases and faulty heuristics we use when making decisions and predictions in "Thinking Fast and Slow" http://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp/...

Arrays are not sequences in Scala. They are Java arrays, not Scala sequences.

.........and the sad thing is now everyone will buy it.

It sounds like you're suggesting apathy instead?

To say it's a moot issue because there are technical work arounds is pretty naive. I seriously doubt any major browser would ship with a work around to this...I don't know why you assume they would.

Not using the side by side format, sorry.

http://www.nevercertain.com/2011/08/17/scala-ruby-rosetta.ht...

Given how much more popular automated testing and TDD have become in the past 7 years since that book was published (and much longer for some of the sources cited for those data), I'd be very surprised if we haven't gotten much better at that particular form of testing.

Also I'm quite curious how you can actually count the number of bugs found from each of these methods. Test-after unit testing would even be preventative if you wrote tests immediately after writing the code. If doing that made you think about more edge cases and thus fix up the code then it seems like those bugs would not get counted.

Seems like many of these would have different amounts of a preventative effect that would be difficult to measure....especially if you wanted to isolate their effect from each other.