Ethereum would represent a counterexample to this thesis. However, looking at their forum's Project and Smart Contract sections, I don't see any actual projects at all. Am I missing something?
You're looking in the wrong place. The forum is full of "ideas for projects", its hard to sift out the projects with code. Try the github instead
. You can find five functional clients in different programming languages: cpp-ethereum (C++ - aimed at developers), go-ethereum (Golang - aimed at users), pyethereum (python - vitalik's client), ethereumj (Java - aimed at an android version), and node-ethereum
(unofficial but quite functional). All have screenshots and/or screencasts somewhere.
There are three higher-level language compilers, written by their respective client authors. Each compiles contract code (LLL in cpp-e, Serpent in py-e, and Mutan in go-e) to EVM (ethereum virtual machine) bytecode. Cpp-e also incorporates serpent (serpent->LLL->bytecode), and so does go-e. All five clients have a different EVM implementation that can run the same bytecode.
Additionally, there's a new, fourth high-level language at the concept stage, codenamed Solidity
. The purpose of this fourth one is to provide formal descriptions of contract interfaces. These formal descriptions will be the basis for a DApp permission system, to provide wallet security without sacrificing usability. It will do this by translating formal interface descriptions into english language permission requests:
Untrusted ŠApp "Foo Sprocket DApp" attempting to transact in your name:
Send 45.780 GAV from the account of Your Name Here to an account accessible only by Foo Sprocket DApp.
Do you wish to allow this?
This will enable use of DApps seamlessly with user wallets. Should be a much improved experience over the tedious, error-prone task of copy/pasting deposit, payment, and withdrawal addresses between users' wallets and the third-party services they wish to use. (QR codes aren't much better)
Also in the official repo is an initial, proof-of-concept "randomized" proof-of-work mining algo
. It generates a new circuit/problem every so many nonces (a nonce is a hash attempt - ie 100k hashes per second is 100k nonces per second). So every 512, or 1024 nonces, a new random hash function is generated. The parameter balances the time-spent-generating with the time-spent-evaluating. Too large and FPGA's would have an advantage over CPUs (an FPGA takes time to reprogram, but after reprogramming would be faster at evaluating than a CPU). Too small then there's more time spent generating than evaluating. Obviously, the mining algo is at a very early stage and who knows if they'll actually succeed at ASIC/FPGA resistance (the reason its desirable is a debate in itself), but at least its an active project.
These are all lower-level projects, at the platform/backend level. There are also projects at the user-level, i.e. DApp contracts with front-end interfaces. The most prominent of these would have to be GAVcoin
and the exchange
(these need to opened from within an ethereum client to work properly). The exchange is demoed here
. There are plenty of example contracts