There is an inherent simplicity in HTML / CSS / JS that can be easily forgotten and difficult to replace. Each has its responsibility: Organization, Style, and Function
I agree in the simplicity of HTML and CSS if we're talking about simple websites. I've found that for more complex apps, and especially if you're using features of newer, half-specified standards (with style prefixes etc.) things can get a bit out of hand. One thing I want to point out is that you can separate your Dub code by style and function if you want to, although I can understand if you do not want that option.
My thinking is that HTML has limitations, and can cause a lot of repetition. That's one of the reasons for the abstraction (along with avoiding the need for three separate languages), but I can understand that some people might prefer it as is.
Would you mind explaining what you mean by "the lack of opinionated language design infers on code"? Are you referring to the fact that it's not specialised for either layout or presentation?
No. Javascript is just a general purpose language. It could very well serve as a DSL for layout or presentation. But the browsers already have that, it's called HTML and CSS.
What I'm referring to is Javascript syntax. It's way too ambiguous which often leeds to programming errors. For instance: the global variables gaffe, the scope mess, the sloppy prototypal implementation, etc.
Hiding that behind a compiler doesn't make the problems go away. It makes them worse.
For what it's worth, my intention is to overcome some of those issues that you mention. First, I assume you're talking about accidental pollution of the global scope (by omitting 'var'), which can be avoided: see CoffeeScript. Also, I have some ideas to improve the 'scope mess', as well as prototypes.
If it's possible to change the title, please prepend with Show HN. Some people (including me) like to vote just for the sake of it. There was a discussion here to vote up Show HNs to support those who ship (can't remember the link though).
I can't see how the compiled code for Type is supposed to work?
If you deference a JS function from an object, you lose the context of `this`. So in
Ruby.prototype.cut = function () {
this.shape(); this.polish();
};
var old = Ruby.prototype.cut;
Ruby.prototype.cut = function () {
old(); this.engrave();
};
`Ruby.prototype.cut` will be called with `window` as `this`, so `this.shape` will be undefined. Use `old.call(this)` to get the behaviour you want.
Accurate-enough (sub-second in my case) timing of events + physical proximity (both your browser and the app ask for your location) = a near guarantee that your browser session + your phone is a unique pair. It also asks for confirmation on both the phone and browser to pair the first time.
There's no real chance of this being man-in-the-middled since you have to confirm on both devices. And they're being intelligent about it - I just tried it with two laptops at once, and you get "someone's device" instead of the name of your iThing, and your iThing says "please try again" like this: http://cl.ly/1O33430M0i2c0i2T0z2U
Once you've approved, they have a browser + app pair of cookies for future pairings (not really exploitable, as it runs over https), which strengthens the single-pair guarantee to the point where it's about as good as it gets in any security model.
>* Exactly what's keeping the cookie on the browser and the phone from being copied?*
SSL. Either you trust it or you don't. Similarly, either you trust the CAs to work (preventing a real MITM on https traffic) or you don't. Which makes this as secure as your banking site, except for the initial pairing, which I dare say they do more safely than any bank I've seen.
Since the block reward is the only source of 'new' bitcoin, the rate of bitcoin creation will be halving as well. So there will be two competing effects:
1) 'monetary' inflation will decrease, because the rate of bitcoin creation will drop from 7200BTC/day to 3600BTC/day
2) miners will be earning half as much when denominated in BTC
If the decrease in inflation doesn't cause a large enough corresponding increase in price, mining would be less profitable, causing some fraction of miners to drop out, and meaning longer transaction confirmation times (for at most 2 weeks, while the network adjusts to the change in capacity).
My guess is that the huge change in inflation will adequately compensate both miners and investors, and cause a significant enough increase in price to avoid lengthening confirmation time.
> ...and meaning longer transaction confirmation times (for at most 2 weeks, while the network adjusts to the change in capacity)
To be clear, it wouldn't be two weeks. The network adjusts every 2016 blocks, which under normal circumstances would be approx. 2 weeks. Typically it's a little less as new hash power comes online, but in the case of a drastic loss of hash power, it could be much much longer than two weeks. We saw that with namecoin where it took almost half a year between adjustments (or would have, if developers hadn't intervened with merge mining).
Inflation is not directly proportional to the supply of money. If a bitcoin's value versus the US$ drops (as it has since June), there is heavy inflation as the price of goods and services (measured in bitcoins) goes up.
I don't really have any expectations; there are so many variables to consider.
My guess, however, is that the price will be more stable, given that the effect of any bad news won't be so amplified by the minting of new coins. Currently, the supply of coins is growing rapidly (just over 30% per annum). After the block reward halves, that rate will be below 13% per annum.
As others have mentioned, I'm also curious to see how the halve will affect the network's hashing rate (and therefore, security).
Thanks for your kind words.