I think the key point of this article over the other related article ( http://news.ycombinator.com/item?id=284192 ) is that John points out that tracing will be able to be applied to DOM manipulation/property access in the future. "Being able to trace through a DOM method would successfully speed up, not only, math and object-intensive applications (as it does now) but also regular DOM manipulation and property acces…
speed up, not only, math and object-intensive applications (as it does now) but also regular DOM manipulation Agreed. The sooner they get to that, the better! Edit: As an aside, the web arguably wouldn't have happened without "stealing code". I see this as a strength not a weakness.
John Resig on TraceMonkey
11–20 of 21 posts
Re: John Resig on TraceMonkey
#12check out Steve Yegge's video/transcript about dynamic language optimization in case you missed it: http://steve-yegge.blogspot.com/2008/05/dynamic-languages-st...
Things have been moving in this direction for quite some time, I think. Here's a master's thesis from March 2006: http://www.cs.wustl.edu/~plezbert/contcom/
Re: John Resig on TraceMonkey
#13I think the key point of this article over the other related article ( http://news.ycombinator.com/item?id=284192 ) is that John points out that tracing will be able to be applied to DOM manipulation/property access in the future. "Being able to trace through a DOM method would successfully speed up, not only, math and object-intensive applications (as it does now) but also regular DOM manipulation and property acces…
speed up, not only, math and object-intensive applications (as it does now) but also regular DOM manipulation Agreed. The sooner they get to that, the better! Edit: As an aside, the web arguably wouldn't have happened without "stealing code". I see this as a strength not a weakness.
Re: John Resig on TraceMonkey
#14Has anyone run a comparison between this new engine and SquirrelFish yet? It seems to me like two major ideas are competing: 1. Better JIT for interpreters. 2. Faster interpreters, period. I'm really curious to see which has the faster ramp-up and which has the best end-game results.
Re: John Resig on TraceMonkey
#15Earlier quoted context omitted.
speed up, not only, math and object-intensive applications (as it does now) but also regular DOM manipulation Agreed. The sooner they get to that, the better! Edit: As an aside, the web arguably wouldn't have happened without "stealing code". I see this as a strength not a weakness.
I'm not against open sourcing code, or giving away helpful small things, but at the moment anyone can copy every bit of useful functionality of a JS application and just create their own back-end. That is a very ridiculous concept, and there isn't much that can be done about it if that person isn't within the same country.
Re: John Resig on TraceMonkey
#16Earlier quoted context omitted.
I'm not against open sourcing code, or giving away helpful small things, but at the moment anyone can copy every bit of useful functionality of a JS application and just create their own back-end. That is a very ridiculous concept, and there isn't much that can be done about it if that person isn't within the same country.
It might be more valuable to avoid basing your business on artificial scarcity to begin with.
Re: John Resig on TraceMonkey
#17Earlier quoted context omitted.
It might be more valuable to avoid basing your business on artificial scarcity to begin with.
Well, I guess if the business model were to not make a significant amount of money then no scarcity would be perfect! But really, scarcity (real or "fake") needs to exist or else I would be wasting time creating a PRODUCT (in other words: something that is sold).
Not true: see 37signals, for example.
Re: John Resig on TraceMonkey
#18Earlier quoted context omitted.
Well, I guess if the business model were to not make a significant amount of money then no scarcity would be perfect! But really, scarcity (real or "fake") needs to exist or else I would be wasting time creating a PRODUCT (in other words: something that is sold).
> scarcity (real or "fake") needs to exist or else I would be wasting time creating a PRODUCT (in other words: something that is sold). Not true: see 37signals, for example.
Re: John Resig on TraceMonkey
#19Earlier quoted context omitted.
It might be more valuable to avoid basing your business on artificial scarcity to begin with.
Well, I guess if the business model were to not make a significant amount of money then no scarcity would be perfect! But really, scarcity (real or "fake") needs to exist or else I would be wasting time creating a PRODUCT (in other words: something that is sold).
Re: John Resig on TraceMonkey
#20Earlier quoted context omitted.
> scarcity (real or "fake") needs to exist or else I would be wasting time creating a PRODUCT (in other words: something that is sold). Not true: see 37signals, for example.
I think you misunderstand what artificial scarcity means (or I do somehow). 37signals is proof that artificial scarcity must exist in some form to profit. Adding a price to something creates a form of artificial scarcity. From my perspective, you just agreed with me.
Scarcity and want must exist in order to set a legitimate price. Artificial scarcity sets a price on something that isn't actually scarce. It is a (unfortunate?) side-effect of the market that potential buyers think that because something has a price, it must be worth having (ie scarce). I don't think there's actually anything wrong with basing a business on this, but don't be surprised when your customers realize you've been selling them something that should have a price closer to zero because there is infinite supply.