Itching my programming nerve(armstrongonsoftware.blogspot.com)
armstrongonsoftware.blogspot.com
Itching my programming nerve
http://armstrongonsoftware.blogspot.com/2008/06/itching-my-programming-nerve.html
15 comments
Interesting idea with the open source stock exchange. I always assumed that one can't simply launch a stock exchange, it has to be highly regulated and expensive to get into (just like not just anybody can start a bank). Not sure if that is the case, but the "open source" part made me think, perhaps in developing countries it could be useful. Perhaps people could just have local stock exchanges, and the government wouldn't even care.
I always assumed that one can't simply launch a stock exchange, it has to be highly regulated and expensive to get into
Steve Wunsch tried it in the late nineties with the Arizona Stock Exchange (http://www.businessweek.com/1997/09/b3516129.htm).
Interestingly, the hard part is less about regulation than market forces.
You have to have listing standards (i.e., do the companies listed really exist, are their financial records accurate, etc.) that traders will trust, and you need a critical mass of buyers and sellers to start using it.
Steve Wunsch tried it in the late nineties with the Arizona Stock Exchange (http://www.businessweek.com/1997/09/b3516129.htm).
Interestingly, the hard part is less about regulation than market forces.
You have to have listing standards (i.e., do the companies listed really exist, are their financial records accurate, etc.) that traders will trust, and you need a critical mass of buyers and sellers to start using it.
You don't need (want?) to launch an exchange these days. What you do is launch a so called "dark pool", an opaque matching engine, to provide liquidity.
Then there are ECNs like http://www.batstrading.com/. See http://en.wikipedia.org/wiki/Electronic_communication_networ... and google for Island, Instinet or BATS.
Then there are ECNs like http://www.batstrading.com/. See http://en.wikipedia.org/wiki/Electronic_communication_networ... and google for Island, Instinet or BATS.
The point is the same: creating a dark pool (like an exchange) is more a market forces challenge, less a technical one.
I.e., you still have to attract a critical mass of traders to your platform, and once there, you have to figure out how to deal with anonymity, backing away, and gaming issues.
Even LiquidNet, despite its success in this niche, still has these problems.
I.e., you still have to attract a critical mass of traders to your platform, and once there, you have to figure out how to deal with anonymity, backing away, and gaming issues.
Even LiquidNet, despite its success in this niche, still has these problems.
I voted you up even though I don't understand what you are talking about. But it sounds interesting...
The dark pools, or liquidity platforms, match orders up before they reach the exchange. Basically you have big orders sitting in the pool and waiting to match up with passing traffic. These orders are not publicly visible, so you get less price transparency than if all orders are matched through the exchange.
Actually, when I said open source I really meant the stock exchange software. Oh, well...
I meant that too, I was just thinking about who could use such a software. I don't think the big players will adopt your open source solution? So I thouhgt about the third world application.
Some interesting stuff there.
Not sure about the wiki - if it doesn't fully implement everything MediaWiki does, it may be too early to compare performance (80/20 thing). CouchDB on the other hand is very promising, as a whole new DB concept.
Not sure about the wiki - if it doesn't fully implement everything MediaWiki does, it may be too early to compare performance (80/20 thing). CouchDB on the other hand is very promising, as a whole new DB concept.
CouchDB sounds interesting, but the wiki thing is the opposite of a "killer app" -- I'm sure it's a nice demo, but MediaWiki is a seven year old app. As a PR exercise, it just serves to enhance Erlang's unfortunate reputation as a great language for writing prematurely optimized code that ships late. If you want some positive PR, rebuild Twitter, and do it before 2010. Better yet, build something new, or something profitable, or both.
They say this thing is "faster" than the current Wikipedia, but they don't really say how much faster. Benchmarks are deceptive. Where's the cost-benefit analysis -- you're asking me to have one of the world's top Erlang hackers rearchitect an app in a language that only a handful of expensive, talented people can understand, and for what? Will the Wikimedia foundation save $10k per year? $100k?
And, when Wikipedia's competitors start adding features, will the foundation discover that the cost of modifying their super-optimium Erlang app completely outweighs the savings in server hardware? Wikimedia isn't in the telecom industry: They don't have a monopoly, and their specs might have to change more often than once every decade or two.
They say this thing is "faster" than the current Wikipedia, but they don't really say how much faster. Benchmarks are deceptive. Where's the cost-benefit analysis -- you're asking me to have one of the world's top Erlang hackers rearchitect an app in a language that only a handful of expensive, talented people can understand, and for what? Will the Wikimedia foundation save $10k per year? $100k?
And, when Wikipedia's competitors start adding features, will the foundation discover that the cost of modifying their super-optimium Erlang app completely outweighs the savings in server hardware? Wikimedia isn't in the telecom industry: They don't have a monopoly, and their specs might have to change more often than once every decade or two.
You are obviously focusing on the presentation-layer (mediawiki) and completely ignoring the data store that everyone else is quite psyched about.
Here is what scalaris provides: distributed, fault-tolerant, replicated key-value store (a la Dynamo/SimpleDB.) This layer can be smeared out across hundreds or even thousands of nodes, it can provide data consistency across the replicas (via Paxos, something that SimpleDB/Dynamo cannot provide and pass back to the application layer for reconciliation) and it can do this rather quickly.
That is a rather powerful component to make readily available to any Erlang app. If you can't think of ten or twenty possible applications of this then you are not trying hard enough.
Here is what scalaris provides: distributed, fault-tolerant, replicated key-value store (a la Dynamo/SimpleDB.) This layer can be smeared out across hundreds or even thousands of nodes, it can provide data consistency across the replicas (via Paxos, something that SimpleDB/Dynamo cannot provide and pass back to the application layer for reconciliation) and it can do this rather quickly.
That is a rather powerful component to make readily available to any Erlang app. If you can't think of ten or twenty possible applications of this then you are not trying hard enough.
"If you want some positive PR, rebuild Twitter, and do it before 2010"
Twitter is already done: http://twoorl.com/
Without all the users of course.
Twitter is already done: http://twoorl.com/
Without all the users of course.
They didn't implement a Wiki. They implemented a distributed storage backend in which the Wiki pages are stored.
It's worth mentioning here that Joe Armstrong developed Erlang for his thesis work.
Not really. Erlang was born out of practical experiments in language design with the explicit aim of finding a better way to program telephony applications. The experiments were done over a few years in the second half of 80s at the Computer Science Laboratory at Ericsson.
Joe's PhD thesis which describes the design decisions and Erlang's philosophy was published much later, at the end of 90s IIRC.
Joe's PhD thesis which describes the design decisions and Erlang's philosophy was published much later, at the end of 90s IIRC.