dete

When we started the project, we expected to use a standard, eBay-style, rising auction with successive bids, but that resulted in way too many on-chain transactions. So, we had to find a kind of auction that required just two committed transactions: Starting the auction, and claiming the winning bid. The answer was a descending clock auction, where you set some start price and gradually drop the price over time until someone chooses to pay. (It's formally equivalent to a first-price, sealed bid auction, if you're an auction theory aficionado!)

The common name for a descending clock auctions? "Dutch Auction" or "Tulip Auction". The irony is not lost on us...

There's no way to prove it, but all the members of our team have pledged not to trade in cats in any way. We are definitely not manipulating the price.

I can assure you that we're as surprised as anyone at the speed that this thing has grown!

I understand this position, but when the money involved is crypto -- which is inherently highly "launderable" -- I'm not so sure. Why run your money through a cat when you could run it through a mixer?

The first release will be Ether only, but we hope to enable non-crypto payments soon after. (Behind the scenes everything happens in Ether, on the Ethereum blockchain.)

We ran an alpha challenge during ETHWaterloo this weekend, on one of the Ethereum testnets. The official, mainnet release is still scheduled for November.

I believe Twic was paraphrasing me, and then asking if my statement (and thus his paraphrase) were satirical.

It was a joke, and I intended it to work regardless of your opinion of Perl and Larry Wall himself. With that said, my own opinion is that Larry Wall did a bunch of interesting things in Perl (some of them merely out of ignorance!), that continue to shape modern languages. The Perl community continues this tradition today experimenting with lots of different programming paradigms, to the benefit of the wider development world.

Well, you can consider it mentioned to the author... that would be me!

I shouldn't have tweaked Java so mercilessly since I did love the language for so long (lo, these many years ago). However, I do think you really underestimate the compile speed of Go. Even if 99% of your builds are incremental, you can't entirely discount the occasional clean build. While it has been many years since I hacked Java, even incremental builds could take more than a few seconds. Even a clean build on our 50 kloc Go codebase clocks in under 2 seconds (0.1s when the disk caches are pre-warmed).

As for generics, I do like them, and seeing them on iOS (with Swift) is a pretty big win. I'm not entirely convinced that Go is much poorer without them, however. The type system in Go is really unique; if you tried to program Go using Java-style paradigms, there's no question that you'd find it pretty disappointing. However, Go does allow some new ways of thinking about types that allow a degree of flexibility that simply can't be expressed with formal class hierarchies.

If what you're doing works for you, just keep on truckin'. But if you give some of these new languages a chance, you might find the areas where they really shine. We did!

Semantic Databases can easily encode that kind of statement, adding any new kind of relationship is quite straightforward.

That particular relationship is outside the goals of DBpedia, which is primarily intended to represent the "summary blocks" that appear in the upper-right corner of major pages on Wikipedia.

Freebase allows anyone to make new relationships, though, so you could go into Freebase today and encode those dependencies if you had sufficient source data. This leads to it's own problems! It's common in Freebase to find the same conceptual relationship encoded using multiple different relationship classes. For example, we've seen more than ten different ways of encoding geolocations within this one dataset!

Semantic Databases are remarkably flexible, but -- as with Javascript! -- this flexibility can be its own curse...