paulhodge

It's still too scary/hard to purchase BTCs (wire transfers to foreign banks, sending in a picture of your driver's license, that kind of thing). Once you can buy BTC from a reputable US site using easier payment methods, then we'll get to see an even bigger bubble.

Fair point, most of the mistakes were on the author's part. MtGox isn't completely blameless, they had a cross-site scripting vulnerability, and they should probably enforce some stronger security around logins from new computers. Something like Steam's approach where every login from a new computer needs to be verified with a confirmation code.

Would love to hear more details on this; why can't the 21m limit be changed?

I haven't tried it yet, but if I was going to sell BTC for USD I would give this one a go: https://fastcash4bitcoins.com/ They only buy BTC, and it's a fixed price instead of an of exchange.

Or more likely.. the Bitcoin developers release a new version that allows for more than 21m coins. I think a lot of people don't realize that Bitcoin is still an actively developed beta-version software project. There are several parts of the code that the devs are already thinking about changing (such as the way that transaction fees are calculated, or increasing the number of times you can subdivide one coin). If the 21m limit becomes crippling, I'm sure they will change that too. Really, they can change anything they want as long as they can convince 51% of pool owners to upgrade.

If tulips had a near-zero storage cost (ie they didn't go bad), and a near-zero transmission cost, and if they supported anonymous ownership, and if the process for generating tulips was more fair, and if the speed of tulip generation was guaranteed to slow down, then tulips probably would have made a decent form of currency too. Other than that though, totally the same thing.

First question, yes, I think you'd be talking about a timespan of months before seeing a reward as a lone miner.

Joining a pool is pretty painless though. You just create an account, and probably give them an email address, and then start running GUIMiner or something. You also give them a Bitcoin address to send the rewards. That's it, no other personal information needed.

If you just want to dip your toes in the water, you could always start mining. Doesn't take any initial investment or bank information or anything like that, just processing power.

Of course, it's not going to crash very far if enough people are thinking this.

Personally I would just fabricate a very intelligent-sounding report where I claim to have found a serious, exploitable flaw in Bitcoin's encryption. I don't think it would be too hard to convince people, because many people expect that something like this might happen. And if the fabrication is good enough then it'll take days or weeks for researchers to fully evaluate the claim. In the meantime the uninformed panic causes a price dip and I buy a bunch of cheap coins.

With lots of data there's no doubt that they are measuring something, but it's not clear that they are measuring what they want.

Your breakfast analogy would be more like:

- Some days Alice eats crumpets while sitting in her house and it takes her about 20 minutes.

- Some days Bob eats a bagel while on the way to work and it takes him about 5 minutes.

- Therefore, bagels are 4 times faster to eat than crumpets.

See the problem is we have conflated lots of correlations at once. There is 1) a tendency for certain types of foods (languages) to be used for certain purposes, and a tendency for certain kinds of people to prefer certain foods (languages), and neither of those correlations are necessarily caused by the properties of the food (language) itself.

I love these updates, the tool is looking more awesome every day.

I'm wondering if there's a roadmap for Light Table's release, specifically if there's a point where the code will be available? I have a programming language in progress and I'm interested in potentially hacking LT to support the language. It seems like it would be a good fit.

Using open source software as a counterexample is not a good idea, since we don't have the foggiest idea what the rate of success is. What percentage of people who sit down to produce open source software are actually successful, and what percentage just read HN/Reddit instead? Is it 10%? 1%? 0.1%? We never hear about the failures, so who knows.

Then a competitor could just provide the same "super" features for free. Facebook's best strategy is to profit off the network/user base itself, since that's something they have that no one else does.

When your game does regain control, it can run the simulation for N steps (however many it usually does for the given dt), then finally render the scene using the latest state. (so the game will appear to pause, then skip ahead). Or it can try to play catch-up, it does 1 tick and render at a time, but with a reduced delay between frames until it's "caught up". (so the game will pause, then appear fast-forwarded for a bit).

Either way Tlark is right, you really don't want the game logic to be affected by framerate.

1984 was a long time ago, I think most/all compilers ended up adding this optimization at some point.

It is somewhat complex to do it correctly, see: http://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html

People focus too much on percentages of installed users. Better to look at the total user count (and compare that to the engineering cost of supporting the platform). It doesn't matter if OS X has 3% or even 0.1% of users. If the number of addressable customers is high enough, then it can be worth it to support that platform.

If we were talking about an ordinary creation, like a physical object, then I'd agree with you.

Creative works follow different rules though. The most successful ones become part of our shared culture and they permanently infect our brains. They become part of our jokes and our metaphors. You can't opt-out.

The most extreme example is Happy Birthday. Because of copyright, you can't legally take a recording of your child's special day and share it with others. It's a ridiculous situation, especially for such a basic song.

It's fine for the author to reap the rewards of their creation, but there needs to be some limit. 50 or so years is not asking too much.

> One thing people usually understand as part of "message passing" is "no shared state". How/where do you fit that in?

Good question, it seems like all definitions of message passing involve not sharing state. Even OOP emphasizes data hiding as a core practice.

Sure, with enough boilerplate code you can do anything in anything. It's more of a categorization of what's the normal style, of what is already provided and encouraged.

In the interests of rigor I'm going to propose a ranking system. A higher rank means more "Message Oriented".

Rank 1: Polymorphism. You can "send" a message to an object. You don't know or care exactly what the object does. Other than the polymorphism, the "message" behaves just like a function call. It will definitely be handled by your target object, and it will definitely return instantly with a response. The compiler might even be able to inline this function call.

As seen in: Pretty much every OOP language.

Rank 2: Messages as first-class values. It's possible to write a function that forwards all incoming messages to another object, based on some logic. The caller does not know what will happen to the message. However, the message can be expected to be handled instantly, and it may respond instantly (if it does have a response).

As seen in: Objective-C, Smalltalk

Rank 3: Asynchronous messaging. When sending an outgoing message, it might be placed in a queue and handled at a later date. The message does not return a result instantly, so agents must have some other mechanism (such as including a "reply to" address) to be able to talk back and forth. From the perspective of the caller, it's a bit like putting a message in a bottle and watching it drift off to sea.

As seen in: Erlang, message queueing libraries.

Yeah, there's a huge Javascript bias. When they describe a dev with 7 to 10 years experience as: "Web Hipster; I was using AJAX before it was even called AJAX.", it's a bit like hearing nails on a chalkboard.

You can read their whole explanation, it's an interesting read: http://strikedebt.org/debt/

Short answer: various methods of systematic trickery and financial booby-trapping perpetrated by, you guessed it, the 1%.

I bet it would be interesting to have a graph of tickets over "number of days until the end of current month"

Something that would probably be worthy of a blog post: the Google results in the Bing It On challenge are unfairly neutered.

Try doing the Bing It On search for something like "radiohead". You see two columns of plain old search results, both are fine. But if you go straight to Google.com and search for "radiohead", you get more than just the normal search results, you get a bunch of extra details on the right side of the page. Those extra details are super relevant and helpful, like the band's members, popular songs, upcoming events, etc. If you go to Bing.com and try the same thing, it also has some extra stuff on the right, but it isn't nearly as good.

This happens for lots of searches. Google often shows some really helpful domain-specific information, but that extra stuff doesn't show up in the Bing it On challenge.

I've also starting having some awful performance hitches involving Flash, which might be related. Sometimes if I watch a Youtube video, the whole browser window (not just the current tab) locks up for a few seconds. Just started happening a few days ago, on Chrome for Mac.

> 1. Is Bret Victor now the Linus of cutting-edge programming environments?

Linus actually implements his solutions to things that he rants about, and releases his code, so that analogy isn't quite right. Bret gives us nice big-picture ideas and leaves the implementation for others.

I think many of the specific ideas mentioned by Bret will quickly fall apart when trying to actually implement something non-trivial. But that's okay, it's useful to have a really inspiring big-picture vision.

It would definitely make the engine implementation more simple and elegant, but why exactly would that be worth it? Why would that be worth all the downsides?

I think a good analogy, say that I'm implementing a database. In my database, every single time it handles a query, it always does O(n) search across every record to find matches. The implementation would be so simple and elegant!

> It also had a large number of people who pointed out all the reasons why it wouldn't work.

To be fair, it's not actually possible to present a new idea on this forum (or any forum with technical-minded people), without getting a flood of reasons why it won't work.

Number 10 is a total apples-to-oranges comparison. For an apples-to-apples comparison, the question is, do you want to give your contributors write access to your master repo? (and deal with the consequences)

If contributors have write access, then Git is almost as easy. There's just one more command ("git push") compared to SVN.

If contributors don't have write access, then there's no easy way to do this with SVN. Most places that I've seen will either have users submit .patch files via email, or put their changes in SVN branches (ugh). Or, they convince themselves that they'd rather just give contributors write access. Either way, Git has many handy ways to solve this problem (Github pull requests are just one of those ways), and it definitely wins on this front.