Show HN: A simple way to get options prices for free - <AUTHOR> http://www.strategic-options.com/insight/how-to-get-option-prices-for-free-api-yahoo/ <comment><USER2> Note that you can't redistribute this data or generate income through it [0] per the Yahoo TOS [1].

Also note that Yahoo's data is somewhat unreliable [0, 2].

Unfortunately options data is just hard to get access to due to the agreements forced on providers by the exchanges. If you want to build a trading system on it without an institutional budget, the best options I've found so far are QuantConnect [3], which has paid for it and lets you build your system on their platform and OptionWorks [4], which you can pay $150 for and download all the data. You should be able to get a live feed from your broker after that. If you want it for academic research, many universities and colleges have access to much higher quality data.

This should be fine for personal use though.

[0]: [https://meumobi.github.io/stocks%20apis/2016/03/13/get- realt...](https://meumobi.github.io/stocks%20apis/2016/03/13/get-realtime- stock-quotes-yahoo-finance-api.html)

[1]: [https://policies.yahoo.com/us/en/yahoo/terms/product- atos/ap...](https://policies.yahoo.com/us/en/yahoo/terms/product- atos/apiforydn/index.htm)

[2]: [https://seekingalpha.com/instablog/6052771-kevin- wrotenbery/...](https://seekingalpha.com/instablog/6052771-kevin- wrotenbery/2413952-is-yahoo-finances-historical-data-accurate)

[3]: [https://quantconnect.com](https://quantconnect.com)

[4]: [https://www.quandl.com/databases/OWCS](https://www.quandl.com/databases/OWCS)

<comment><USER3> Another good source for option prices is: [https://datashop.cboe.com](https://datashop.cboe.com)

I would not recommend to use the Yahoo or Google apis to get option prices. Some of the bid/ask prices are completly wrong and some expiration dates are missing. I created an option scanner as a side project and found about this bad data quality the hard way.

<comment><USER2> It's a good place to get solid data but it's quite expensive. EOD history for SPX alone is $250 apparently. All symbols are $2500 and my understanding is that this is just CBOE options? Is CME not in there?

<comment><USER4> $250 is not bad... what does it include?

iVolatility told me it would be ~$1000 for EOD chains + IV & Greeks since 1990 - just for SPX. CBOE is partners with iVolatility so I imagine their data is decent, but I can't bring myself to drop that much on it for a simple personal project.

<comment><USER5> With IV and greeks from 1990 is $384.62 apparently: [https://datashop.cboe.com/option-quotes-end-of-day-with- calc...](https://datashop.cboe.com/option-quotes-end-of-day-with-calcs)

Since CBOE is the exchange itself, I'd assume the quality of the data is at least the same as iVolatility, if not better.

</comment></comment></comment></comment></comment><comment><USER6> The TradeKing API has quotes, including options quotes. I think all you need is a TradeKing brokerage account and then you can get an API key.

[https://developers.tradeking.com/documentation/market- option...](https://developers.tradeking.com/documentation/market-options- search-get-post)

</comment><comment><USER7> Is option prices what I think of when I think "Stock Data"? I've been wanting to download and play around with processing "Stock Data" but I don't really know what I'm looking for. What metrics are stocks judged by? I'm assuming price is only one of many things.

<comment><USER5> > Is option prices what I think of when I think "Stock Data"?

You may be thinking of simply stock prices or stock fundamentals (income, expenditures, that kind of stuff) but you may also be thinking of other things like sentiment or analyst opinions. There's a huge range of things you can look at. Options prices are certainly one kind of stock data though, they give valuable information like implied volatility (how much the market at a particular time expects the stock to move in a particular period in the then future).

If you're interested in stock data, Quandl ([http://quandl.com](http://quandl.com)) has a broad selection of the different kinds available (though you don't have to purchase there) and Quantopian ([https://quantopian.com/](https://quantopian.com/)) has some examples of how to use it.

To be clear though, options are not stocks.

A stock is a share of ownership of a company. You buy it, you sell it, that's it.

An option is a contract between you and another party that gives you the right but not the obligation to buy or sell a stock at a particular price for a certain amount of time.

Practical examples:

\- I buy 10 AAPL stock at $100. I now own $1000 worth of Apple. AAPL's stock price rises to $110. I now own $1100 of AAPL stock, which I can sell and make $100.

\- I buy a contract that gives me the right to purchase AAPL (an AAPL call option) for $100 (the "strike price" is $100) which expires in 30 days. This right is limited to 100 AAPL shares and I pay $500 for it. For the next 30 days, regardless the price of AAPL stock, I can buy 100 AAPL for $100 each. If the price of AAPL drops, I lose the $500 I paid for the rights. If the price of AAPL rises to the $110 from earlier, I can either buy 100 shares of AAPL for $100 and sell them immediately for $110, making $1000 - $500 (for the contract) = $500, or I can simply sell the rights to someone else and make the profit more cleanly.

This isn't meant to be an exhaustive course on how each security works, just an illustration of exactly how different they are, yet affect each other.

</comment></comment><comment><AUTHOR> I posted this here because after many years, it has proven difficult to get simple options prices. There seem to be a lot of paid services and misinformation.

</comment><comment><USER8> This guy [1] has written a neat post on generating option data from historic raw data. Would be quite interesting to compare the results on 1-minute data compared to raw prices. It seems OK for longer holding periods, where you'd mostly look to use options as directional leverage on underlying large caps.

[1]: [http://www.financial-hacker.com/algorithmic-options- trading/](http://www.financial-hacker.com/algorithmic-options-trading/)

<comment><USER5> I've seen this too but I don't think it's particularly valuable as it seems to base the prices on measured volatility, while the actual market prices them entirely differently. You can see in his chart at the bottom that the price diverges from real data by a full dollar at points and that's just for SPY, I'd be interested to see how it goes for something like VIX.

<comment><USER4> It doesn't really work using VIX either. At the end of the day, using any constant across the options (measured volatility, VIX, etc.) you're assuming a flat volatility surface which you simply don't see in the real world.

A better approach might be to use some kind of avg volatility surface with VIX as a baseline, but even that leaves you with no sentiment.

For some strategies this might work well enough (e.g. a flat volatility surface implies a lot of 50/50 probabilities), but for any advanced historical analysis (which seems to be the scope of this post), you really need to have the price/IV of evry individual option.

</comment></comment></comment><comment><USER9> I tried using this and got really excited when I thought I found some options that were grossly mispriced (indicating that I could buy them, immediately exercise them, and make a hefty profit). Turns out that Yahoo just has bad data sometimes.

</comment><comment><USER10> At QuantConnect we offer minute level options trades&quotes for your backtesting. Its 400TB of data :D. (I'm founder of QC). To backtest it we run it on 5GHZ water cooled machines! We play with really fun toys :D

</comment><comment><USER11> Since you are using Yahoo and presumably option for further analysis .. you can get Option data in R using the following three lines:

```r

require(quantmod)

OPTS <\- getOptionChain("AAPL", NULL)

OPTS

```

Python, Julia, etc have likely similar functions and other packages for Option and Trading analyses

</comment><comment><USER12> You can also use symbol=CMG170915P00580000 to get a specific strike and save a lot of bandwidth, unless you happen to need the entire series or all series/expirations

</comment><comment><USER13> Related, a simple way to get historical minute by minute data for stocks [http://126.96.36.199/recommend/datasets](http://18.104.22.168/recommend/datasets)</comment>


Download, print, build your Martian home in 24 hours - <AUTHOR> http://www.bbc.com/news/business-29208276

<comment><USER2> See the printer at the University of Southern California Viterbi School of Engineering. I worked in Dr. Khoshnevis' lab as an undergraduate there 10 years ago. He seems to be about 10 years ahead of other 3d printing technologies at any given time. Here is the home page for Contour Crafting: [http://www.contourcrafting.org](http://www.contourcrafting.org).

The cool part the BBC story leaves out is that they print with material that simulates what the science community anticipates martian and lunar soil will be like!

<comment><USER3> > The cool part the BBC story leaves out is that they print with material that > simulates what the science community anticipates martian and lunar soil will > be like!

We should be launching habitation fabrication equipment as soon as SpaceX has the lifting capacity for it!

</comment></comment><comment><USER4> >"While some embraced the idea in a heartbeat, others felt this project discredited their art and profession."

I doubt it. Most single-family residences are already something picked out of a catalogue of generic designs.

<comment><USER5> Having lived in many such homes... yeah, can confirm. Single-family residences are _very_ generic, with very minor differences in design nowadays, at least in the western half of the States where I am.

I have a feeling these architects feeling "discredited" are the ones whose work in the field of single-family homes is very much discreditable. Unless you're going for some fancy one-off custom architectural job for your home, you're buying something that's already pretty cookie-cutter.

</comment></comment><comment><USER6> This seems similar to what Andrey Kudenko did here: [http://www.cnet.com/news/worlds-first-3d-printed-castle- buil...](http://www.cnet.com/news/worlds-first-3d-printed-castle-built-house- next/)

</comment><comment><AUTHOR> To me this is part of software eating the world. It seems like a good idea, and probably is, but now architects have to become software engineers. No longer can they rely on the builders to sort out the uneven land or the plans that are off by 2 mm.

Its perfect or it does not go "compile".

Software really is eating theworld.

<comment><USER3> > but now architects have to become software engineers.

As you said, software is eating the world. In the end, you won't have doctors, lawyers, architects, aviators. You'll have software engineers/developers who understand medicine, law, building trades, and flight.

Once you understand concepts, everything else is just syntax.

<comment><USER7> I guess it's not just physicists: [http://xkcd.com/793/](http://xkcd.com/793/) :)

It's more likely we'll see domain experts in X learn sufficient programming (possibly leveraging custom tools and DSLs), rather than see programmers mastering X.

<comment><USER3> > It's more likely we'll see domain experts in X learn sufficient programming > (possibly leveraging custom tools and DSLs), rather than see programmers > mastering X.

Depends on the domain. Are most of the Watson developers medical doctors? It already diagnosis cancer at a better rate than a second year medical student.</comment></comment></comment></comment>


Stock options are complicated - <AUTHOR> http://www.benkuhn.net/options <comment><USER2> In my experience most people at startups who leave end up not exercising their options due to the cost of exercising them coupled with the fact that they may be underpaid due to the assumption that their options may end up quite valuable. So basically they pay somebody 90k/year then give them ~20k/year in options. Then they quit after 2 years and have 90 days to buy like 50k worth of stock at the strike price they were promised.

So they end up paying 50k to buy some common shares (not preferred). An investor who paid 50k to invest in the company most likely got preferred shares, so the young guy who paid 50k who probably can barely afford that is now taking way more risk for a much smaller percentage of the company. If the company goes under the preferred shareholders have a chance to get their money back during a firesale of assets or IP or whatever, but the common shares are screwed.

So I tell virtually everybody unless there is a well established secondary market to sell your shares of your particular company, then don't take the options.

I honestly think the 90 day exercise is totally ludicrous in the startup world. I think that should be a major negotiation point with anybody who is joining a startup. They should just insist on it no matter what.

<comment><USER3> Not to mention $90k person is likely leaving because they have low faith in the company in the first place.

<comment><USER4> Just playing devil's advocate here: So they are leaving because they have low faith in the company, but still expect to be able to collect rewards on other peoples' work years later if the company happens to succeed?

If they didn't have a high degree of confidence in the company, the safe bet would always be to not exercise.

<comment><USER5> This mentality is dangerous and pernicious. We have vesting schedules for a reason. They'd be reaping the rewards of their past work, not other people's future work.

</comment></comment></comment></comment><comment><USER6> I can't help but feel the system is highly rigged in favour of investors.

Many countries have tax incentives for investors, but when it comes to people actually joining startups, investing their time and effort, then all you get is a tax bill - and mostly at a highly inconvenient time to pay it!

It very much feels like the system is designed to keep the rich rich, and to put the working (wo)man in their place.

<comment><USER7> The US is probably the worst in this respect, and I heard Canada is quite bad, but most of European tax systems follow the "pay taxes only when money comes your way" principle, which puts all investors on equal footing.

<comment><USER8> What is the trap / bad part in Canada?

<comment><USER9> When you exercise your SO, you need to pay taxes, based on current price of shares, even if you don't sell them right away. SO is a joke in Canada.

<comment><USER10> I fail to see how that's different from the US. Stock option exercises of vested shares are taxable here, too.

</comment></comment></comment></comment></comment><comment><USER11> After working at 4 different startups over the past 10 years I can tell you with a very high certainty that the only people who will make much $$$ from options are founders and investors.

Early Employees generally are shafted. Don't think your 20-200 basis points will be worth anything at the end of it. Make a decent salary and avoid companies that work you to death. Take it as a learning experience and look at the options as pure monopoly money.

EVERYTHING is skewed towards founders and investors.

<comment><USER12> Do you have voice and power in future negotiations about the direction and equity breakdown of the company? If so, the promises are worth something. If not, they likely are only worth enough to convince you to not sue about it, because that's what the actual incentives are in future capital negotiations.

</comment></comment><comment><USER13> Stock options are not complicated. Most people who look into the details of them will find them very plain and actually quite simple. The issue is you don't often deal with this area of finance so it looks foreign until you spend some time looking into the terms.

Your options are a contract between you and the company for you to buy shares at a given price.

If the value of the shares is worth more then you pay, the difference is income. "Value" is a 409a valuation ask your CFO what it when you execute.

Enter the accountant who will tell you how much your liability is for that income ( it varies no more then a dozen other factors affecting your yearly taxes )

Your shares are illiquid, and likely worthless. VC's and other institutional investors have contracts with the company that means they will get paid well before and much better then you. This should really be the first point since you should have known this when accepting your compensation package.

<comment><USER14> Agreed. Takes maybe a few hours to understand the terms.

BUT, most technical folks are very uninformed about investing and finance in general. Many brilliant engineers at my previous employers were utterly confused about their options as well as their decision making after IPO.

So I think the difficulty also stems from a lack of development in financial acumen generally.

<comment><USER13> +1 for development of financial acumen. We can often point to people taking out 18% APY car loans, or going to Payday loan vendors and say how silly they are for not understanding finance, but we turn a blind eye when its the finance that effects us ( even though one could argue that compounding interest on a payday loan is probably more complex then your basic stock option grant )

</comment></comment></comment><comment><USER15> Just a bit off topic: I'm from Brazil, working as a contractor for a company in the US. They offered me stock options and I'm totally lost about this. Not only because this isn't normal in Brazil, but, the majority of the articles in the wild only focus in the US scene. I want to know more about how this works when you're not in the same country as the company. Will I be double taxed (in US and Brazil)? On what rules I'll be able to exercise my options?

</comment><comment><USER16> Regarding stock options expiring 3 months after leaving the company, it doesn't have to be this way and a lot of startups are moving in the direction of 10 year exercise periods.

I think Quora was the first to do this: [https://dangelo.quora.com/10-Year- Exercise-Periods-Make-Sens...](https://dangelo.quora.com/10-Year-Exercise- Periods-Make-Sense)

<comment><USER17> > Regarding stock options expiring 3 months after leaving the company, it > doesn't have to be this way and a lot of startups are moving in the > direction of 10 year exercise periods.

This requires converting all options to NSOs, and the tax implications of NSOs are not pretty. (From a _tax_ perspective, ISOs aren't great[0], but they're much better for employees, by design).

[0] You have to pay AMT on the spread between the option price and current value at the time you _exercise_ , whether or not the equity is liquid, so you could end up paying a large tax bill only to find that the company goes bankrupt before you have the opportunity to ever sell your equity.

<comment><USER18> The kicker here is that the option life is 10 years, even if you have left the company. So you can avoid tax by not exercising until you plan to sell. It becomes a personal choice between 1) do i want the option still, even if i quit, and 2) do i plan to have ownership in the company for a period longer than a year before i sell. Typically most people would prefer 1 over 2.

Keep in mind for someone reading this comment, this is about private companies.

<comment><USER7> The other thing to keep in mind is that stock options (especially those given to employees) tend to be much less protected than shares.

If you exercised, and another shareholder got unfair preferential treatment, you have reason to seek compensation or sue. If you haven't exercised yet, .... well ... not so much.

Also, many option contracts give you the right to buy X shares at price Y and do not make special consideration for stock splits - e.g. a 2:1 split would likely make your options worthless by halving the share price, and by halving the percentage of the company that X represents.

So, waiting to exercise until you sell is a very good strategy, except when it isn't - not very common, but you rarely get notified about these issues beforehand, especially if you are no longer involved with the company.

</comment></comment></comment></comment><comment><USER19> AMT and the 90 day limit on exercising after leaving a company are the main things that make options painful. There has been some movement in the industry to get away from the 90 day limit (by converting from ISOs to NSOs), but has there been any recent attempts to get the AMT rules changed for ISOs? Does anyone think the current AMT rules for stock options are fair? I'm curious how this is viewed by people outside the industry.

<comment><USER20> There was an effort last year to pass a bill to fix the AMT horror show with regards to options last year.

[https://www.congress.gov/bill/114th-congress/house- bill/5719](https://www.congress.gov/bill/114th-congress/house-bill/5719)

I think ironically to the bubble many of us live in the Silicon Valley, this was proposed by a Republican and passed in the House. Never made it in the Senate. A refreshing reminder good ideas still come from all slices of our political spectrum.

<comment><USER21> Everyone hates the AMT; very roughly Democrats think it's a broken tool for addressing a real problem, and Republicans see the problem it addresses as a good thing.

</comment></comment></comment><comment><USER22> This is great write up. Kudos to the author for taking the time. I did have a question about the following sentence:

>"If an employer gives you straight-up shares, then the IRS will tax the shares (at ordinary income rates) when they vest."

What would be treated as income and taxes here, the strike price x the number of options vesting? Is that correct? For regular worker bees this not very much though right? For instance say an employee has 25 shares vest in a quarter and their stick price is $20. 20 x 25 would be $500 more being taxes as income. Or am I completely not understanding something?

If it is not the strike price being taxes as income what is it, since the the value of an option is often unknown to rank and file employees let alone the IRS.

<comment><USER23> Shares vested x fair market value at vest. So you get 1000 shares when you join, worth $1/share. 250 vest on your first year, and that's when tax is due. But say the company grows and shares are $5/share. 5x250 is 1250 taxed income on the anniversary. Normally at early stages you're talking many thousands of shares though, that can increase rapidly.

The fmv is recalculated every year, or on any fundraise events. It needs to be a defensible number or the irs will be upset

<comment><USER22> >"The fmv is recalculated every year, or on any fundraise events."

This is the piece I was missing. Thank you for the clear explanation.

That being said it would be interesting to buy exercise them just to see what the company is actually valuing those options at, since this is often opaque to the average worker. I wonder if it's possible to exercise a single option and use it as a barometer of sorts to quantify you actual compensation? My guess is no.

<comment><USER23> I've never had a company refuse to give me the 409a valuation if I asked point blank for it(just say you're considering exercising and it's important for tax planning). It's important to keep in mind though they tend to purposely depress that value. But investors get a premium because their stock has legitimately more value than yours(liquidation preferences, board seats, etc). And without a liquid market, if you do sell privately you end up taking a large discount. I think the opacity is largely that it's difficult to value things, not so much nefariousness

<comment><USER22> I see, I guess you just need to know to ask for it. I imagine many(most?) do not. I find these discussions and these types of articles really helpful. I would like to think we are all becoming more savvy about these a result. Thanks for the tip.

</comment></comment></comment></comment></comment><comment><USER24> Stock options are definitely complicated, but so are your taxes. In fact, your taxes are much more complicated. However, there exist reasonably good software tools, eg TurboTax, to represent your taxes as a decision tree, and to walk you through it.

The problem isn't really that stock options are complex -- it's that there doesn't exist comparably good software for stock options.

I'm actually building software to solve this: [http://www.optionvalue.io](http://www.optionvalue.io). Right now it covers value in exit scenarios, but am currently building out exercise / tax scenarios.

</comment><comment><USER25> This doesn't mention transfer restrictions at all, and that's an altogether different reason that options are complicated. It's a bad idea to assume that you'll be able to sell private company shares, even if the company is popular and you've heard of other people selling. The existence of a market for the shares doesn't guarantee that you'll be allowed to get rid of them, because the company can enforce all manner of restrictions on sales.

The market for stock in a private company tends to be very small. Existing investors and prospective investors in the company can comprise most or all of it. Those folks care more about relationships with the company than getting their hands on a handful of employee shares. What this means practically is that if the company doesn't want you to sell for any reason, the buyers won't cooperate with you either.

If you're planning on selling, you should feel comfortable communicating this to the company. And they should agree to it. And that assent should be very recent and in writing.

You can find startups out there willing to buy derivatives on your exercised shares, which is functionally similar to selling shares. But this is a mixed bag, and you should read those terms carefully.

Read your option agreement. You'll note that among other things, it says that the agreement can be amended by the company at any time to say anything at all. Good luck!

<comment><USER26> > Read your option agreement. You'll note that among other things, it says > that the agreement can be amended by the company at any time to say anything > at all. Good luck!

That is likely not actually usable because there may be no consideration [1].

[1] [https://en.wikipedia.org/wiki/United_States_contract_law#Con...](https://en.wikipedia.org/wiki/United_States_contract_law#Consideration_and_estoppel)

</comment></comment><comment><USER27> I (respectfully) disagree entirely with this conclusion.

If you want to do analysis like this, you need to weight these numbers against the possibility of it happening to get the expected value of each column. You have also simplified the smaller exit values to not include investor preferences (which means investors are first in line to get money, founders second, employees dead last).

Additionally, most contracts do not allow for early exercise so lots of these ideas are moot. If you do not have early exercise in your contract and you leave the company it's usually a leading indicator of failure. Either the company laid you off to reduce burn (do not under any circumstances buy stock if you have been laid off), or you left the company for a moral/business/whatever reason. In the latter case, it seems unwise to put your money where your heart isn't.

If you are optimizing your life for the best chance of striking it rich do not be a startup employee. Be a founder. Better yet, be an investor.

There are lots of reasons to be a startup employee, but being in it for the options is not one of them. Treat them as worth $0 and negotiate for more cash or things you care about like vacation or part time hours.

<comment><USER28> Founders and investors are generally at the same place in line. Both hold common shares.

<comment><USER27> If your investors have liquidation preferences, that's not true and can leave founders with nothing depending on the exit.

If there are no liquidation preferences, then you are correct.

<comment><USER28> _sigh_

I meant to write founders and employees. Not founders and investors. Sorry. Not sure I screwed that up. The screwup made my statement completely wrong.

Investors, as you helpfully point out, generally have preferred stock with liquidation preferences and hence are "first in line."

</comment></comment></comment></comment><comment><USER29> In case you're holding stock options of a US company but need to pay your taxes in Germany I can highly recommend this article (in german): [http://www.pinkernell.de/esop.htm](http://www.pinkernell.de/esop.htm)

</comment><comment><USER30> Serious question: why does the IRS insist on valuing private company stock on the basis of a 409a valuation without taking into account whether a market for it even exists? The 409a is paid for by the company which (as the article mentioned) has an interest in keeping it lower. And holders of common stock in private companies, in most cases, can't actually liquidate their holdings (leaving apart cases like pre-IPO Facebook which traded in secondary markets). So the stock is effectively worthless no matter what the 409a says. There shouldn't be tax due until there's a liquidation event that allows shares to be sold.

<comment><USER31> Given the tax scheme is published well in advance, they certainly seem to be worth something---else who would take them?

<comment><USER30> Stock options and private stock are taken in the hope that they'll be worth something someday, not because they're necessarily worth anything at present.

It's all well and good to say "X is the fair market value of this stock based on factors y, z and a"* . But when no market exists (or severely restricted ones where sellers have to take a loss) then that value is not relevant (or should be discounted appropriately).

* I tried looking up (briefly) whether the absence or presence of a market for the company's stock is taken into account for a 409a valuation but couldn't find anything.

</comment></comment></comment><comment><USER32> The recommendation to immediately transform your options to shares and sell them is the exception rather than the rule. In this context, it is assumed that options are very illiquid.

But in general, if you want to recover as much as you can, you should sell your options directly. That is why the value of an American and a European option tends to be the same.

[https://en.m.wikipedia.org/wiki/Option_style#Difference_in_v...](https://en.m.wikipedia.org/wiki/Option_style#Difference_in_value)

</comment><comment><USER33> I listened to a software engineering daily episode where this: [https://github.com/jlevy/og-equity- compensation#introduction](https://github.com/jlevy/og-equity- compensation#introduction) was discussed. Found it cleared some things up.

</comment><comment><USER34> I'm getting into trading options but I don't work for an employer who grants them to me.

I'm curious, can you sell your options without exercising them or are the kinds of options you get from an employer not the kind of options you buy from an exchange?

<comment><USER35> The two types of options are similar in that they have the same general terms. However, you cannot sell your ISOs on the CBOE, because they differ in details, the most important one being that the exchanges only trade in options for publicly traded companies.

That doesn't mean you can't sell your ISOs to someone else; there just isn't a marketplace for it.

</comment></comment><comment><USER36> I wish I could purchase my ISOs within my IRA, avoid all these tax issues.

</comment><comment><USER37> I still think start-ups should offer the equity, it helps motivation and retention. But also offering a well-defined bonus program would give a lot of the benefits to employees while not having to pay out as much in equity. Then employees are getting the benefits of the company doing well even if their stocks are still effectively worthless.

</comment><comment><USER38> This HN post nails it.</comment>


3D Food Printers Could Change What You Eat - <AUTHOR> http://www.digitaltrends.com/cool-tech/3d-food-printers-how-they-could-change-what-you-eat/?utm_source=Sailthru&utm_medium=email&utm_term=DT%20Newsletter&utm_campaign=DT%20Newsletter%202015-04-26

<comment><USER2> OK, not arguing with the premise of the article, but is anyone out there boggled by the sheer lunacy of the situation, in which we are attempting to create a machine that can print food in 3 dimensions!?!

Imagine that, 3 dimensional food. I swear the world has gone mad from a certain perspective. haha, where will it end.</comment>


Ask HN: Resources for Understanding Windows Better? - <AUTHOR> MacOSX is intuitive because of its Unix origins, but the OS designs behind Windows confuses me, and I'd like to know it better. Also, I'm confused about design decisions behind having two different versions of settings in Windows, and it seems like there are two different file paths for commonly used folders like Downloads. Whenever I have to tweak something on Windows, I have to check tech blogs, but I'd rather just get a consistent, reliable resource to learn more about Windows. <comment><USER2> I doubt there is such thing and that you can learn windows waterfall way. You need to use it and fight ad hoc problems. There are many different solutions to any problem.

Microsoft puts compatibility features topmost and that is the reason for multiple ways to do any thing. Sometimes I hate it, but if I think about it more clearly its a big asset to know that stuff you know will always work on Windows even if it get 'deprecated' by newer stuff.

IMO, you should learn to do any Windows configuration with PowerShell. You will have consistent interface for everything and as additional benefit you will learn shell very well and can bring it on with you to *nix world.

Regarding books, Windows internals is great one but probably not what you seek (mostly low level stuff). Sysinternals stuff generally is great way to understand and dominate Windows.

[https://www.microsoftpressstore.com/store/windows- internals-...](https://www.microsoftpressstore.com/store/windows-internals- part-1-system-architecture-processes-9780735684188)

</comment><comment><USER3> Gall's law: " _A complex system that works is invariably found to have evolved from a simple system that worked._ "

Windows evolved across several generations of PC technology dating all the way back to the original 8086, major shifts in consumer expectations, and major shifts in vision in the leaders who managed Windows development. Windows is successful because it evolved to fit its role and Windows is also messy because it evolved to fit its role.</comment>


Making MathBox: Presentation-Quality Math with Three.js and WebGL - <AUTHOR> http://acko.net/blog/making-mathbox/ <comment><USER2> Regarding the use of three dimensions for visualization, see Tamara Munzner's forthcoming book, "Visualization Design and Analysis: Abstractions, Principles, and Methods." [1] Although still in draft form, the section "No Unjustified 3D" is relevant:

> Many people have the intuition that if two dimensions are good, three > dimensions must be better – after all, we live in a three-dimensional world. > However, there are many difficulties in visually encoding information with > the third spatial dimension, depth, which has important differences from the > two planar dimensions.

> The cues that convey depth information to our visual system include > occlusion, perspective distortion, shadows and lighting, familiar size, > stereoscopic disparity, and others. This section discusses the costs of > these depth cues in a visual encoding context, and also the challenges of > text legibility given current display technology. It then discusses in what > situations the benefits of showing depth information could outweigh these > costs, and the need for justification that the situation has been correctly > analyzed.

> In brief, 3D is easy to justify when the user's task involves shape > understanding of inherently three-dimensional structures. In this case, > which frequently occurs with inherently spatial data, the benefits of 3D > absolutely outweigh the costs, and designers can use the many interaction > techniques designed mitigate those costs.

> In all other contexts, the use of 3D needs to be carefully justified. In > most cases, rather than choosing a visual encoding using three dimensions of > spatial position, a better answer is to visually encode using only two > dimensions of spatial position. Often an appropriate 2D encoding follows > from a different choice of data abstraction, where the original dataset is > transformed by computing derived data.

Although I'm not sure I would recommend it, you can do 3D in D3.js by extending the DOM to represent a 3D scenegraph. For example, with X3DOM: <http://bl.ocks.org/1291667>

[1] <http://www.cs.ubc.ca/~tmm/courses/533-11/book/>

<comment><USER3> I'm well aware of the complications, however, I've found a lot of it comes down to priming your audience. I used subtle orbiting motions, slow transitions and reference grids to let the audience see where the depth was at all times. I haven't tried adding real shadows or SSAO, but it would only enhance this. There's also 3d displays to consider.

I think part of the problem is that we haven't had good tools to do this with. My mental sketchpad is in 3d, mathbox is what it looks like.

<comment><USER2> If you are trying to understand three-dimensional functions, it makes sense to view them in 3D. I was just pointing out that in the domain of information visualization (separate from math and scientific visualization), 2D is generally preferred for perceptual reasons.

<comment><USER3> ... that's kind of why I made it a point to mention d3.js and heap lavish amounts of praise on it in the article. Which you read, right?

<comment><USER2> Indeed, thank you! Hugs all around. :) You made the argument that D3 doesn't do 3D because of the DOM, and I just wanted to clarify that while this is mostly true (caveat custom elements such as X3DOM), the reason is perceptual as much as technical.

</comment></comment></comment></comment></comment><comment><USER4> The github link is <https://github.com/unconed/MathBox.js>

As a math/visualization geek I'm smitten by this.

Loved this quote:

"I wasn't 100% sure whether other people would have the same a-ha moments that I've had, but I'm convinced more than ever that seeing math in motion is essential for honing our intuition about it. MathBox not only makes animated diagrams much easier to make and share, but it also opens the door to making them interactive in the future."

It's stuff like this that makes me pine for better WebGL support across the board.

</comment><comment><USER5> While I enjoyed the article, I found its presentation to be very distracting. The rotational-scroll effect, font choice and the breaking of the back button hurts the page's usability.

<comment><USER6> I agree.

The library and visualizations were great, but the demo page can take some polishing still.

I really didn't understand that anything I did on the page (scrolled down to read more text, clicked the left/right arrows under one of the illustrations) was going to affect my browser history, and was puzzled when I failed to get back here with a single click on Back. Very surprising, and actually quite annoying.

</comment></comment><comment><USER7> An impressive amount of work went into making this page. Everyone is complaining about the JS and breaking the back button, which is a shame, because if you look past that bug you see some great visualizations and content.

</comment><comment><USER3> Oh hackernews, i knew if i came here I'd find people bitching about some inconsequential detail.

<comment><USER8> It looks absolutely amazing, and I loved the visualizations. If I had this in early calculus, or even _before_ that, in middle school when I was first learning to program but hated maths, it would have been amazing.

I see a ton of potential down this route, thank you for sharing.

I do worry that it requires a sharp mind to be able to design visualizations clearly, but that's likely a problem all education faces - and fails at - regularly, but it goes unmentioned because of the nature of textbooks and isolated schools.

</comment></comment><comment><USER9> I was at full frontal and this presentation was captivating. One of the best talks I have ever seen. Bravo.

</comment><comment><USER10> Beware, the page spams your history while you page through it.

</comment><comment><USER11> Hey unconed, is it possible to drop mathematical functions into this? Or do you have to code them in?

What I mean is can this partially replace Mathematica? Can we type a mathematical formula and have the software build the animations?

<comment><USER3> You have write a JavaScript function to calculate the data points. There is no editor or UI for it, but the API is pretty simple. There are examples on GitHub, view source on this for example:

[http://acko.net/files/mathbox/MathBox.js/examples/ComplexExp...](http://acko.net/files/mathbox/MathBox.js/examples/ComplexExponentiation.html)

</comment></comment><comment><USER12> A friend asked me to provide him with some screenshots since he doesn't have WebGL, and he thought others might also find it helpful:

<https://www.dropbox.com/sh/o547nsd7atgg7xa/tF2E2sYaef>

</comment><comment><USER13> Stevens talk at Full Frontal was absolutely fantastic, one of the best I have ever seen. I highly recommend watching the video once it comes out. It is very impressive to see such complex topics being presented with such ease and style.

</comment><comment><USER14> Had to turn off JavaScript to access the page. Has anyone else had this issue?

</comment><comment><USER15> This webpage breaks inertial scrolling on my iPad.

<comment><USER16> Can't read past the fold on mine

<comment><USER3> This is a rare webkit bug I reported 9 months ago and which still hasn't been fixed. A refresh should fix it.

</comment></comment></comment><comment><USER17> I'm sure this is a nice library, but it really needs a fallback better than "please get WebGL" for the many users who currently see only that error message.</comment>


Damian Conway on Perl and its future - <AUTHOR> http://www.oreillygmt.co.uk/2010/05/damian-conway-on-perl-and-its-future.html <comment><USER2> _I usually say "I agree. Sad, isn't it. Ah, well."_

A wise opening anecdote. "Dead language" trolls have very little experience and even less wit. If you bother trying to spend the time to properly refute their arguments, they'll go off on a tangent about market share, mind share, and other very ephemeral things. It's often easier to let them walk away feeling right and get back to business.

Dead-language-haters are in my experience, are a vapid and eccentric lot. The majority of them have a lot of criticism for something they have absolutely no experience with or knowledge of. Damian does a great job of pointing this out in the interview without being as snarky as myself. He has an infinite amount of patience for Perl's critics it seems. I cannot count the number of times he's had to repeat the same arguments over and over. Even with the overwhelming amount of evidence he backs his statements with, people still keep asking him if Perl is a dead language.

That's why I think waving them along and getting back to work is a great idea. Let the smug weenies feel right and wear their proud little smiles as they walk away. I'm sure their satisfaction with themselves will keep them coding for many weeks to come. In the mean time real people with real work to do can get back to doing what they do best. In their un-hip dead-language of choice.

Great interview, Damian. :)

</comment><comment><USER3> "Recently Martin Drashkov wrote "Why Perl lost It" (<http://martin.drashkov.com/2009/11/why-perl-lost-it.html>). "

OMG, I'm famous! Now that fame is here, fortune must be right around the corner. ;)

I wish I spent more than half an hour ranting there. I could have made a much better argument, especially concerning new programmers and Perl.

<comment><USER4> > neither Perl5 nor Perl6 seem to offer much for developers

Saying that Perl 6 offers nothing is just ridiculous. If a fast and solid implementation appeared today it would blow the competition out of the water.

<comment><USER5> I am quite excited about Perl 6 features (not a fan of the syntax though ... coming from Python). While I enjoy Python, I would actually consider using Perl 6 because of features like macros, regex etc. I am not sure if Perl 6 has TCO. However, I would be a little bit concerned about using Perl 6 (rakudo) in any sort of production system before say 2013 or so considering that Parrot has just started to add some critical pieces[1] like JIT and threads. I suppose based on the interview Perl 6.1 would coincide with that.

[1] [http://wknight8111.blogspot.com/2010/05/fitness-of-parrot- as...](http://wknight8111.blogspot.com/2010/05/fitness-of-parrot-as-target- platform.html)

<comment><USER6> _I am not sure if Perl 6 has TCO._

It does.

 _I would be a little bit concerned about using Perl 6 (rakudo) in any sort of production system before say 2013 or so considering that Parrot has just started to add some critical pieces[1] like JIT and threads._

Why? Do you use Python or Ruby or PHP now?

<comment><USER5> > Why? Do you use Python or Ruby or PHP now?

Don't get me wrong. I like Parrot. Its just that IMO complex pieces like JIT, threads and GC take some time to stabilize. So while I am all for Perl 6 being on Parrot and Parrot seems to be quite a feature rich VM I would want to see it used in the field for at least a year before I use it for a critical application.

For the same reason, I would probably pick up the JIT/unladen-swallow version of CPython (whenever it comes out) only about a year or so of being out.

At the moment I use Python quite a bit and have started to use Ruby sometimes. No PHP. Perl 6 and Parrot appeal to me because of their feature set. As for the syntax, I prefer Python syntax much more than Perl 5/6 but thats subjective. I would very much want to try out Perl 6 as it brings a lot of good stuff to the table, I think syntax would be a small price to pay for those features.

<comment><USER6> You don't have to use concurrency or JIT in Rakudo Perl 6 now. These systems do take a while to stabilize, but they're not requirements for any Perl 6 applications. As for the GC, it'll always undergo tuning and experimentation. Even so, if it doesn't work, we'll know and we'll fix it.

</comment></comment></comment></comment></comment></comment><comment><USER7> I think Perl's _market_ success came largely with the internet, and the need for CGI script (though it was popular before then, as a sysadmin tool, it really took off with the net). It's hard to replicate that market success, without some similar wave (true in general; I'm not singling out perl).

Damian mentions some cool features; but I'm getting a Lisp vibe: clever people use it, they develop cool new things with it, but it doesn't attain market success (aka _secret weapon_ ). Damian himself is a clever guy (though you only hear of his over-complex stuff, the 3 he mentions, using latin, haiku and whitespace); eg. mjd too is great (<http://blog.plover.com/>) and of course Larry. As in Lisp, these clever ideas get adopted into other languages (eg. today, even Java has Perl-style regex).

Fitting in with this is the psychographic profile of the wish to not be standard - to do things differently - which is great (crucial) for research and development; but becoming less great for later stages, such as production code.

My personal view is that both standard and non-standard are important, though necessarily antagonistic.

<comment><USER8> IMHO, the things that Perl really has to do are no so much the clever syntax designs and run-times etc. which while cool to people interested in languages and how they work, don't really allow the language itself to be used in larger scoped work. What Perl needs is a robust standard library that supports the kinds of things that people want to do with languages, like build interfaces, or solid web frameworks. Even better would be retargeting Perl to other languages, like a Perl->JS (so I can write Perl code for a browser) or Perl->JVM (so I can build the kinds of things I need that run on the JVM) compiler rather than building a runtime (Parrot), and re-targeting many languages to that platform.

Don't get me wrong, Parrot and Perl 6 are all worthy efforts. But I'm not sure they will have the kind of impact towards growth of the language and userbase that Perl needs. Perl desperately needs better OO syntax and support for functional programming paradigms. But syntax is syntax, libraries are what make a language useful in today's day and age.

<comment> adam-_- Catalyst is surely a fairly solid web framework. Moose provides a more standard OO syntax...

<comment><USER8> Yeah, I forgot about Catalyst true...

Moose though is an example of what should just be part of the language. I'm glad to hear that Perl 6 will be doing some of what I want, it'll be a good start. But Perl really really needs the kinds of things that people want to use modern languages for. It's still so geared for processing data files (of various sorts), and most of what I see in Perl 6 seems to target this problem in various ways.

Don't get me wrong, Perl is my preferred language, I can crank out a Perl solution to a problem about as fast as I can type it. But when I really want to push the project larger, the language doesn't really do much to help you.

</comment></comment></comment></comment><comment><USER9> "The lady doth protest too much, methinks"

If the majority of your article is spent saying "no, really! We're still relevant, I promise!" then you should take a step back and decide if the group you spend all your time with is bias'ing your views.

<comment><USER10> When you're unable to determine the difference between "the majority of [an] article" and "the first three questions out of eighteen" then you should take a step back and decide if you're reading from the assumption that Perl is no longer relevant rather than with an open mind.

</comment></comment><comment><USER11> _the essential complexity of the code ... will manifest elsewhere_

By using a different language or by writing simpler code, you can avoid every complexity mentioned, so it's not really essential complexity. And programmers in any language can create these problems, except "the intrinsic Python OO worldview," and maybe "weird library APIs". So this sounds like it's really just a criticism of Python.

<comment><USER9> I'm glad you brought this up, I had forgetten that part of the interview. Damien's argument about complexity of data is bizarre given that, due to perls inability to do any nested structures without using perl-refs, complex data in perl is much more effort than in say, python.

<comment><USER6> _...complex data in perl is much more effort than in say, python._

Accessing the first element of the first element of a nested array in Perl 5:

      $aoa[0][0]

Accessing the first element of the first element of a nested list in Python:

       lol[0][0]

Perl 5 references do sometimes produce uglier syntax, but your quibble here is over a sigil.

<comment><USER9> Nested array, fine. Now try that with a hash of arrays of objects with an array member, the 3rd element.

Python:

hash['foo'][3].children[2]

But it's instructive that you assume I'm talking about something as trivial as an array of arrays.

<comment><USER6> Perl 5:

      $hash{foo}[3]{children}[2]

</comment></comment></comment></comment></comment><comment><USER12> It's a little sad watching people who live in the Perl echo chamber convince themselves that Perl use hasn't declined in the last years.

<comment><USER13> I found out something that makes life on HN better.

To avoid the [language war] trolls in stories about Perl, I mention Moose.

Since it is a better OO system than anything in the competition, they generally go away... :-)

Edit: I really wish Lisp was the competition today, I always loved it. :-( I've never used CLOS, but afaik Moose is directly inspired by it (MOP, right?).

<comment><USER14> I'll trollishly bite. I just read [http://search.cpan.org/~flora/Moose-1.05/lib/Moose/Manual/Co...](http://search.cpan.org/~flora/Moose-1.05/lib/Moose/Manual/Concepts.pod). While it does look like a good library that I'd be interested in learning if I'm ever forced to code Perl for monies again, I don't see anything special in it that isn't in other languages or couldn't be implemented in them as a library.

<comment><USER13> Please see draegtun's references, re MOP. (You don't like mixins in Role form? Ah, never mind -- I have real work to do.)

<comment><USER14> What does Moose's mixins in role form give you over Ruby's mixins, or Scala's mixins, or PLT-Scheme's mixins, or just simulating mixins via a multiple- inheritance hierarchy ala Python or C++? I'm not going to spend a ton of time researching, but from what I see at links like [http://search.cpan.org/~flora/Moose-1.05/lib/Moose/Manual/Ro...](http://search.cpan.org/~flora/Moose-1.05/lib/Moose/Manual/Roles.podm), it seems like a nice idea but it's certainly been done before and since in other languages. A lot of the features like method exclusion and aliasing or required host methods could easily be implemented in a library on top of your favorite dynamic language as well if they don't include them natively.

The MOP looks like a necessary tool for Perl's horribly designed OO that wouldn't be necessary for most other languages or could just as easily be implemented as a library. Python and Ruby both have what seems to be the equivalent of metaclasses. Most OO languages have some idea of what an attribute is. And so on. Once again, MOP looks neat, but it's certainly not unique to Moose.

edit: reading the MOP link more carefully, the idea of a class builder builder is more sophisticated than I originally thought MOP was, but as the link says, you're heading into esoteric territory at that point.

<comment><USER6> _What does Moose's mixins in role form give you over Ruby's mixins, or Scala's mixins, or PLT-Scheme's mixins, or just simulating mixins via a multiple- inheritance hierarchy ala Python or C++?_

Safety and correctness.

<comment><USER14> Not sure what you mean. In Ruby, for instance, whenever a module is mixed in a hook method on the module is called. You can enforce any safety or correctness constraints on the parent class that you want at that point. You can easily imagine writing a library in ruby that lets you do the same things as in Moose in terms of correctness and safety. Similarly, you could write your own 'include' method that took extra parameters and performed the same mixin magic Moose is doing like excluding or aliasing methods, performing special handling of conflicting methods, etc.

My main point in all this is that, from my perspective, Moose may have a few bells and whistles beyond the base OO features of other dynamic languages, but these features are more 'nice to haves' than 'essentials. More importantly, these features could also be trivially added in other languages as libraries. Most importantly of all, none of these features is as important as starting out with a clean, well-designed language in the first place, and Perl is anything but clean or well-designed.

<comment><USER6> _Not sure what you mean._

Duck typing suffers from the false cognate problem, and mixins suffer from false cognates and potential collisions. They also do nothing to ensure type safety or optional type-based compile-time optimizations.

 _More importantly, these features could also be trivially added in other languages as libraries._

Non-Moose Perl 5, Tcl, Lisp-pre-CLOS, Lua, and JavaScript to some extent demonstrate the "you can roll your own object system trivially!" fallacy, especially when you want to use libraries written by other people. Likewise, I'm not aware of anyone who's used roles in a serious project who wants to go back to object systems without them.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> This is a great interview. I'm glad Damian took the time to answer those questions.

</comment><comment><USER16> Perl _is_ dead. It's the new Lisp. I can say this as an ex-Perl hacker. But don't get me wrong—they have their niches. I look at this matter with ruthless practicality: code is dead the moment you write it, there is no other way! The only thing that matters is what specific new, awesome code you're building right now in the real world, who is using it, and what they're doing with that code.

So what if folks are speaking a dead language like Latin on a mysterious, magical island that may not even exist, where planes recurrently crash, where time travel is the normal mode of being, and where the line between the living and the dead is unclear. Great! Protect the light!

One thing about the Perl community has always bugged me, and it pops up in any interview with any of the top Perl guys discussing Perl6. It's the notion that Perl code exists in some sort of weird theoretical hacker-academic world, where, like wannabe undiscovered rock stars, or an anointed Software priesthood, they keep saying "this code would be awesome if only everybody would come around, recognize it and then use it." Meanwhile everybody else says "Perl is write-only line noise." If you have to operate this way, I see it as using the wrong tool for the job—code for the living, not the dead!

/anecdotal

I do know I have no reason to go back to any version of Perl after having moved on to Ruby/Rails. It does seem like many more people are contributing code to newer, more bleeding-edge open source projects that have no equivalent in Perl. Especially for the web as it exists in 2010—a lot has changed! Grandma's CGI-style, old-school MVC framework(i.e. Catalyst+mod_perl) won't cut it now. So if you're doing something that requires the new, and you hit up Github or Stackoverflow to see what folks are using, the answer is never "here's a link to CPAN for this awesome Perl module that will blow your mind, help you finish your job, get you kudos from everybody, _and_ get you laid." Instead it's here's the link to Github for this awesome ruby|python|javascript code. (Please prove me wrong here!)</comment>


So You want to be a Programmer? - <AUTHOR> http://dobbscodetalk.com/index.php?option=com_myblog&show=So-You-Want-To-Be-A-Programmer-.html&Itemid=29

<comment><USER2> Interesting list... I found myself disagreeing with several items here, but I think it is only because of my focus on programming. Three years of calculus is overkill in my opinion, though I do think that one year teaches you the mindset enough. But I can see that it is only because I do not do scientific programming.

Same with foreign languages: For me it has been a really important tool being completely bilingual. It has gotten me many opportunities, but again, maybe it's because I'm much closer to the business side of systems analysis than the pure science/engineering side.

Good list. Anyone have any opinions on the items?

<comment> dan-kruchinin > Good list. Anyone have any opinions on the items?

Yep.

1\. First of all calculus is not as important as author says. Actually calculus warps your mind as near any branch of mathematics does. Programming is tied with mathematics very closely and programmer should clearly understand what abstraction is, how to abstract, how to prove, how to create proper aims. And nothing would tell about it as much as mathematics.

2\. math logic.

3\. philosophy and rhetoric. At first sight it may seem boring, but actually it's not. Speech of a good programmer should be constructed well. When you work with guy, who even can't explain you what how his program works, it's not very good. Especially when that guy works in a big team. Rhetoric can _teach_ you how to speak well, philosophy may _show_ you well-constructed speeches.

4\. Foreign language. If you're not a native english speaker, english is first language you _must_ to learn(at least to be able to read technical literature and some papers).</comment></comment>


Deleting $300M by messing around with Ethereum contracts - <AUTHOR> https://hackernoon.com/yes-this-kid-really-just-deleted-150-million-dollar-by-messing-around-with-ethereums-smart-2d6bb6750bb9 <comment><USER2> I just hope that poor guy can still sleep instead of lying awake at night, listening for the soft tapping of the assassins' padded steps on his bedroom floor.

I can imagine someone out there is pretty unhappy with him.

<comment><USER3> on the bright side, that someone won't have any money left to pay assassins.

<comment><USER4> Ouch.

As well, if they do have any money, he just needs to delete it.

</comment></comment></comment><comment><USER5> The thing is, the kind of developers it takes to implement smart contracts correctly is probably exceptionally rare, if they even actually exist.

I don't think it's impossible, but it's clearly in conflict with the "release early, release often" culture. If anything, developing smart contracts is more like building software for NASA crafts : you have to get it right before the launch. And even regarding the NASA, I guess they still have room for some remote patching. In smart contracts, perfect is not the enemy of good, they are actually synonymous.

<comment><USER6> It's not the release culture that is at fault here. It takes age for a language to mature. Relying millions of dollars on an untested language is grounds for trouble.

<comment><USER7> Any idea why the developers chose to develop their own language, rather than just using an existing language that makes sense ?

<comment><USER8> I recently started to code some Solidity, and there are some syntax expressions in the language (e.g payable function) that you wouldn't find in other languages because they don't deal with those concepts. Could you have used a modified version of Java or simply embed those concepts in a library, probably. I guess they wanted a specialized language.

</comment></comment></comment></comment><comment><USER9> The author mentions that turing complete contracts will have bugs in them eventually. While currently that happens, we do have formal verification methods in computer science. And thats exactly what people are trying to apply on Ethereum: Formally verified smart contracts. [https://blog.ethereum.org/2016/06/19/thinking-smart- contract...](https://blog.ethereum.org/2016/06/19/thinking-smart-contract- security/)

<comment><USER10> Formal methods have been under development for decades, yet their penetration into software development is miniscule. Hardly any professional developers know how to use them. Turning Ethereum and its contracts into a formally verified system would be the largest adoption of formal methods by several orders of magnitude.

Ironically, the article you link to does not support your post: it also stresses the difficulties of applying formal methods, and claims instead that various interventions of the sort that have not been particularly successful in securing software generally will be sufficient to satisfy the particularly stringent requirements of a crypto-currency (of course, to say that Ethereum needs formal methods in order to be usable would be to admit that it is not close to being so, so that view will always be contested by the Ethereum foundation. At Cardano [1], however, they do seem to think formal methods will be part of their solution, though I am not sure to what extent.)

This is all mostly moot, however, as the Ethereum we have now is demonstrably insecure by any measure.

[1] [https://www.cardanohub.org/en/home/](https://www.cardanohub.org/en/home/)

<comment><USER9> Yeah true, it is used in some industries such as the space and flight industries, where you want to be sure your code is correct.

However it comes with a range of problems, and often its not worth going into the effort of formally verifying a contract. But with ether, the costs quickly outweigh the ptential losses.

I don't know if it will work, in theory it can, i just wanted to be possitive: I see a light at the end of the tunnel.

</comment></comment></comment><comment><USER11> This is really funny, and hopefully this time people will realise the danger of using programmer-written contracts to manage _millions of dollars_.

If someone can accidentally delete that volume of your money, it's not that someone's fault, it's _your_ fault.

<comment><USER12> Bank accounts, wire transfers that move _trillions_ are also written by programmers, so should we stay to cash economy only? The problem is immaturity of crypto currency/contract market as it's still in its infancy. I'm optimistic about crypto economy future as most of current problems could be fixed (or at least alleviated) by standards, regulations and discipline.

<comment><USER13> _Bank accounts, wire transfers that move trillions are also written by programmers_

Sure, but they're written in ways that humans can generally roll back a mistake and if two humans disagree about what should be done (due to a 'bug' or inconsistency in the contract) there are processes where a third human can listen to their arguments and decide what sounds like the most reasonable course of action. At no point is the code written by programmers the final arbiter of what the 'correct' course of action is.

<comment><USER12> Yet this system is not bulletproof either:

0\. [http://www.telegraph.co.uk/news/uknews/crime/11414191/Hacker...](http://www.telegraph.co.uk/news/uknews/crime/11414191/Hackers- steal-650-million-in-worlds-biggest-bank-raid.html)

1\. [https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery](https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery)

<comment><USER13> Of course no system is completely bulletproof against a determined attacker. There are however a few differences. First of all what these people did is obviously illegal and people go to jail for doing that sort of thing. As it stands there is no legal consensus on whether exploiting a bug in a smart contract is illegal or not.

Secondly and more importantly, the fail-safes built into the system largely work. In the Bangladesh case for example the vast majority of the money they where attempting to steal was never transferred due to humans intervening and overriding the transfer order. And even a non-trivial amount of the money that was transferred was later recovered by reversing the transaction.

<comment><USER12> Exactly. And this is just because there are no regulations _to make it_ illegal and standard protocols to follow that, as I've mentioned in my first post, is the key requirement if crypto economy is to be something more than just a wet dream of crypto-anarchists.

<comment><USER13> But if one of the design requirements that we want/need is that people can override any contract and roll back any transaction, what do we gain from a blockchain/crypto based solution.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> Deleting production database doesn't seem like big screw up after reading this.

</comment><comment><USER6> It just goes to show why developing a mature language is a difficult task. There are situations that were never thought of or some really unintended consequences.

Additionally, for the love of god, why are people experimenting on the main- net? My understanding was Ethereum has a test-net to try and experiment/learn smart contract coding. Is that too different from the main-net to learn stuff?

<comment><USER15> He was experimenting with productionized main net code.

<comment><USER6> You lost me half way there. Experiment and production don't go together. Still what is a productionized main net code? Please elaborate.

Though looking at the screenshots, specially in the third one, he claims to be learning. He was experimenting sending kill() and destroy() to contracts on main net.

<comment><USER15> I can clarify. My point is that the code on the ethereum main net is immutable and permanent. If it wasn't this guy, it would have been someone else, either malicious or not.

If you deploy code to the ethereum main net, it is vulnerable to the world. The issue isn't that the guy was toying with main net contracts, the issue was that the contract was busted, and there was this room for problems.

Ethereum has been extraordinarily prone to these sorts of errors so far (see the DAO). As of now, the foundation is unstable and the stakes are high.

</comment></comment></comment></comment><comment><USER16> How about following solution: Each contract specifies a timedependet 'bounty' for code reviwers. A code reviewer can lock some of his ether in this contract for a specified time. If no vulnarability is found in this time then he gets his ether + % of bounty back. If a vulnarability is found during the time then his ether goes to the bug finder. Everyboddy can see how much ether the reviewers locked in a contract which could increase the confidence of users of a smart contract and encourage bug-searchers to prove that the code-reviewers were wrong. Bounty could be implemented as a % of transactions/deposits of a smart contract - which would ensure that popular smart contracts have many reviews with lots of ether locked to prove it. On the other hand a smart contract wich process only 0.01 ether in its life-time doesnt need reviews at all.

<comment><USER17> If code reviewer doesn't report a bug before the contract is deployed he then can become the 'bug finder' taking all ether from the bounty + his own.

Even if the code reviewer is honest there are some economical problems: \- Code reviewer will find a balance between time spent, amount to put into the time dependent 'bounty' and probability of a bug that didn't come up during review --> little-at-stake problem \- If you force the code reviewer to put in a significant amount of ETH into the time dependent bounty you won't find any reviewers willing to work for you because of the huge risk for them --> risk problem

How would that have worked with the the Parity 'hack'? \- Parity deploying their multisig contracts, having a bounty with code reviewers. AFAIK it wasn't even a bug but a not-well-deployed contract library. So the reviewers would have said that Parity should go on and deploy their multisig contract. Parity would have deployed it in a wrong way (as they did). The 'hack'/accident would still have happened.

If your time dependent contract was separate from Parity's multisig the reviewer would still get his ETH back after the time lock releases. Alternatively the reviewer's funds would also be frozen.

Hopefully formal proof of contracts will save us sometime. Alternatively blockchain with some governance scheme that takes care of something like that would also be useful. Wait a second... Am I describing Tezos? Let's wait for them to launch and see if that works better.

</comment></comment><comment><USER18> That this could even happen - and especially not be reversed - does not bode well for the viability of Eth as 'good for anything'.

If this features continues to exist as part of Eth - it will not likely ever be used commercially.

Even the admins, experts and people working on it don't seem to understand it well enough for it to be safe ...

</comment><comment><USER19> Laic here: Could we not keep Solidity Turing complete as it is and just build a restricted framework on top that will be audited and not Turing complete and just encourage regular programmers to use the framework and its predefined audited functions instead for day to day contracts? Occasionally new tools could be developed in Solidity that will be carefully audited and aded as safe to the regulated framework.

<comment><USER20> How about not having turing complete language where it doesn't make sense?

</comment></comment><comment><USER21> As far as I remember Ethereum smart contracts were designed to be Turning- complete because that would make them "more powerful" than Bitcoin Script. It seems that with great power comes great responsibility...

</comment><comment><USER22> So is there another Ethereum fork incoming?

</comment><comment><USER23> why is the ethereum price unscathed [https://www.coingecko.com/en/price_charts/ethereum/usd](https://www.coingecko.com/en/price_charts/ethereum/usd) despite bad news?

<comment><USER24> Because the entire market cap of Ethereum is $35bn. No one cares. It was a bug in a smart contract -- not a bug in the core platform.

</comment></comment><comment><USER25> Oh jheez

<comment><USER26> Could you please start commenting substantively? We ban accounts that won't follow the guidelines, and we've asked you this already.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

</comment></comment><comment><USER27> There's no way he's "a kid". Through some of his discussions he showed a lot of technical expertise.

<comment><USER28> We debaited the title above.</comment></comment>


The V8 Myth: Why JavaScript is not a Worthy Competitor - <AUTHOR> http://blogs.adobe.com/avikchaudhuri/2012/01/17/the-v8-myth-why-javascript-is-not-a-worthy-competitor/ <comment><USER2> At best, this reeks of like 2000-era Microsoft, "Why does everybody get so excited about Javascript still? ActionScript is way better! Duh!"

As far as actual points in the fine article -- a test using some sort of strongly typed data on an unreleased actionscript vm ran three times faster than v8 running similar code.

I'm not shocked at all, and think Javascript could badly use at the least some type hinting, personally. But, this author is at best just missing it, at worst is misleading others.

I recently ported a Flex app to HTML5. Frame rates quintupled on a modern browser; in a real, mixed-use environment, ActionScript-based tools, interpreted with the Flash or Flex runtime, are roughly one-fifth the speed in the modern browser.

If this speed delta trended the other way, Flash would still be vigorously defended by developers all over the world who would say "we have to have this speed, don't take it away from us!"

<comment><USER3> Out of interest, is there anything you can share about the particulars of your application? We did the same Flash vs. HTML5 analysis in the context of Facebook games, but in our experiments it looked like Flash still won handily in terms of performance.

<comment><USER4> Not just that, even the Google Chrome support for SVG is terrible, it crashes very quickly if you draw a lot of nodes. I also found very simple bugs like moving a SVG objects leaves a trail behind. A good vectorial support is needed to replace flash.

<comment><USER5> It's a constant disappointment to me that Canvas is favoured over SVG. Just drawing simple shapes and moving them is so much more complicated with Canvas.

</comment></comment></comment></comment><comment><USER6> The Web: You are indeed brave, Sir Knight, but the fight is mine.

Adobe: Oh, had enough, eh?

The Web: Look, you stupid bastard. You've got no arms left.

Adobe: Yes, I have.

The Web: Look!

Adobe: Just a flesh wound.

The Web: What are you going to do, bleed on me?

Adobe: Oh. Oh, I see. Running away, eh? You yellow bastards! Come back here and take what's coming to you. I'll bite your legs off!

<comment><USER7> Upvoted not for the humor, but for the aptness of the analogy. JavaScript is universal and free. If Adobe can create a sort-of-compatible environment that allows certain classes of apps like games to run better, great for them. Perhaps their marketing can be, "If JavaScript isn't fast enough, we've got you covered."

At least it's not Dart!

<comment><USER8> It really is appropriate. I love how we keep getting told by guys that are not writing large apps in dynamic languages, that we can't write large apps in dynamic languages meanwhile guys like me are out there building some of the largest code bases in the world with JavaScript. And when it works and we release something revolutionary to the world, they tell us after the fact that it is not going to work. AMD and module dependencies have done far more for advancing building large JavaScript applications than most of these other cures.

<comment><USER9> "building some of the largest code bases in the world with JavaScript" You have over 100 MLoc?

<comment><USER8> You are focusing on the wrong part of the conjecture, the point is, large code bases are being written in JavaScript everyday. Yet, People with the position like the author continue to argue that it can't happen, despite the evidence being readily available.

I don't want to dodge your question thought, the answer is yes I have worked on some JavaScript code bases that are several MLoc. Which I would consider for conjecture sake to rank in the largest. what constitutes that bar is up for debate whether they are the top 50 or 500th or 5000th largest, but I do feel that they qualify as large code bases. Which sufficed for the point I was making.

<comment><USER9> Project complexity tends to scale exponentially-ish, so I was wondering what you considered "Largest codebases"... according to Googling, Windows is 50M, Android 12M. So a couple million LoC is pretty awesome.

Static typing evangelists seem to have a blind spot: they persistently tend to assert that you can't write good and large dynamic codebases.

<comment><USER8> _Windows is 50M, Android 12M_

IIRC in webOS a substantial portion of the user-land utilizes JavaScript, as a whole one could surmise that they constitute modular parts of an overall system. I do not know what the TLoc on webOS is, but I would assume that it would have to be in the ball park of large. I think it is as valid as the total line count of windows or android it is also the problem with looking at these things from just a TLoc perspective.

 _Static typing evangelists seem to have a blind spot: they persistently tend to assert that you can't write good and large dynamic codebases._

Thanks you probably summed up my post better than I did.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> The bytecode myth: Why JavaScript and ActionScript are not Worthy Competitors

Use Native Client. You'll get as close to machine code as you'll ever get, while running in a sandbox. The only way to go faster is to fully trust the code on your machine.

Checkmate.

See, I can write the word checkmate, too. How many more times can we come up with a slightly better argument, using only one train of thought about what is actually a very complicated issue involving multiple vendors, multiple platforms, multiple standards committees, ease of use, ease of deployment, different memory, bandwidth, and cpu constraints, and then just say 'checkmate' as though everyone else is being completely ridiculous?

Several, I bet.

<comment><USER11> "Use Native Client. You'll get as close to machine code as you'll ever get, while running in a sandbox. The only way to go faster is to fully trust the code on your machine."

Nitpick: The only way to go faster is to use the hardware privilege separation that Chrome is always already running under, which is considered insufficient to sandbox untrusted code for historical reasons and organizational reasons (Chrome doesn't have much control over the kernels it's running under), but no technical reasons.

</comment></comment><comment><USER12> I have absolutely no idea how I would write Hello World in Flash. What compiler do I need. Do I need a compiler. Do I need to buy it? Is that all I need?

Compared to:

        $ vim helo.html
        <script>
        alert("hellooooo");
        </script>

And if you can't write that from scratch, ViewSource on most web pages will give you a good clue.

That looks like trump for mindshare, disputed performance questions aside.

<comment><USER13> A couple of months ago I was looking at Flex. It's a complete nightmare to try and play around with. I downloaded the SDK and tried to make some kind of hello world thing but just trying to make a module with a single function and then call that function was not straightforward at all. I didn't even want a module but I have to have one. Fine. How do I make one? The docs don't even cover this sort of thing. There is basically no tutorial or documentation I could find that told me how to do this. I gave up.

Oh, and that was after I had to add manifest types everywhere like I was writing Java, without a free IDE to complete that junk for me. All the docs I found assumed you have the Flex IDE or Flash Builder whatever it is. Which costs over $500. Apparently it's still 1995 at Adobe Inc.

And people say Haskell is hard to use. I had no trouble getting started with Haskell. `ghci<return>` and away you go.

(I'd like to think that it wasn't my fault. Maybe I'm not as capable as I think I am, but I have written compilers and interpreters in C, Haskell, and Lisp. I have written an x86 assembler in Ruby that emits real x86 machine code as Mach-O binaries. I can write hello world in at least 10 languages. I feel like I have the capacity to understand this stuff. Hello world with an existing compiler should be a piece of cake, not an exercise in frustration.)

edit: Ok, I searched for "flex hello world" and did find something that looks like what I want. I deleted Flex and can't try to run it now though. Still don't like all the complexity but it does look like what I said I couldn't find: [http://livedocs.adobe.com/flex/3/html/help.html?content=02_G...](http://livedocs.adobe.com/flex/3/html/help.html?content=02_Getting_Started__23.html)

<comment><USER14> With no Flash experience I had no trouble building a few Flex apps, and it was the same for a team member that quickly build a performant Flex app using their table widgets (which kills something like jQuery data tables plugin even on Chrome).

I did read O'Reilly's Flex book first though. I'm not sure people code Flex for fun, so good documentation costs money.

Was this your first time writing code for a GUI toolkit? Flex has an interesting model that merges XML definition of a UI with module-based code. I don't find it particular complex compared to say, writing an MFC application or C Win32 code to write a UI. I actually prefer it to the jungle of HTML, CSS, JS and dozens of JS libraries which aren't really geared for a professional type UI and fall down when you want to display 10,000 items in your table.

<comment><USER13> Not my first GUI code. I've done lots of web development in the past 15 years. Front and back. I've written an OS X app, several iOS apps including some universal ones, a few Android apps, a few webOS apps, and one Windows Phone 7 app. In a previous life I made games and utilities with Visual Basic and played around with Gtk+ in C (but quickly ran away).

</comment></comment></comment></comment><comment><USER15> I've written both large ActionScript 3 (AS3) projects and large single page Javascript applications so I think I have a pretty good understanding of both languages.

For those of you who haven't done any AS3 programming it is a superset of the ECMAScript 4 standard while browser based Javascript uses ECMAScript 3.1. AS3 "feels" more like Java in that it adds syntax for types and classical inheritance but if you are lazy you can use * for the type and prototypical inheritance still works. Both of those might horrify static language/GOF purists but it does allow you to pass objects around on the side without refactoring pure OOP interfaces or inheritance trees.

In the end I enjoy working in AS3 with its static type checking more than I do Javascript pushed through JSLint. With large Javascript apps, even with strict use of the Module pattern, I feel like my code contains hidden runtime bombs waiting to do off.

Some caveats - I'm on a Windows machine and Flash runs great for me. I've also never developed with "use strict" in Javascript, which I probably should.

</comment><comment><USER16> While the benchmark is certainly valid, he general argument is weak and he comes to a mistaken conclusion.

The argument assumes that compiling a program is a fixed amount of work, hence a AOT compiler will always have an advantage.

This is wrong.

We can chose how much effort a compiler expends, and this choice has a complex relationship with the execution speed of our built program. Read Andreas Gal's PhD thesis, then look through the source of LuaJIT for an example of how one can achieve peak execution speed while spending only a fraction of the time that's typical inside the compilation machinery.

What this means is that AOT vs JIT vs Tracing is a complex topic with no simple winner. Real systems will increasingly be hybrids.

Lastly, wtf does Santa have to do with anything? If you're making a claim, support it with a logical argument and evidence, not a lame rhetorical appeal.

</comment><comment><USER17> "Best performance" is irrelevant if the performance of javascript is good enough.

Maybe this illustrates the dichotemy between traditional engineering and computer science, but in most other forms of engineering you want just-good- enough-to-fulfill-the-requirements because any better means you are spending extra money or doing extra work uneccessarily.

If javascript lets you write a game that runs at a solid 30 frames per second, and write it easily and portably for free, any additional performance is overkill.

For many of the simple types of games people play in a web browser, javascript has been good enough for years. Increased hardware performance will only help javascript.

<http://drblast.sourceforge.net/tetris.html>

<comment><USER18> Just to expand, in most cases 30fps is considered the minimum while 60fps is your target. Most people cannot see the benefit above 60fps. As browsers start using the GPU available on the device in hand then 60fps should be easily attainable; unless you're doing something crazy complicated.

<comment><USER19> I think the problem comes as soon as you need to do any floating point work within the Javascript VM , not sure what javascript FP performance is like but I guess it's not pretty.

</comment></comment></comment><comment><USER20> I'm not an ActionScript hero, so I can't really weigh in on its awesomeness, but the fact that they rewrote it three times and ultimately ended up with a solid language is to be applauded but not surprising. If you were to put the perfect language and smartest compiler into (what I percieve to be) a somewhat kludgy proprietary environment like Adobe's present toolchain, that doesn't strike me as a recipe for win, though. If I'm wrong about the state of affairs there, feel free to educate me.

Dusting off the age-old interpreted vs. precompiled fight as a closing argument strikes me as a little weak as well. If raw runtime performance and the benefits of static typing were the ultimate measure of a language's utility, nobody would write Ruby.

The author would probably be wise to read up on disruptive innovation. The biggest mistake an incumbent can make is to overestimate the importance of the disruptor's weaknesses while the disruptor is busy eating the incumbent's lunch.

</comment><comment><USER21> I've been a Flash developer first before coming to JavaScript. In many ways, ActionScript just may be the superior language. A language's performance is really subjective to its implementation. So lets not argue that. But IMHO, a language's "usability" depends a large part on its community almost like a slippery slope. The larger and active the community, the more tools and libraries are available, the more popular the language get.

</comment><comment><USER22> Some valid points: ActionScript probably is, objectively, a better language than JavaScript.

The article, however, comes across as clueless and obnoxious.

</comment><comment><USER23> This performance claim doesn't seem to match the measurements others have done.

For example, using the code from <http://iq12.com/blog/as3-benchmark/> which I've put up here: <http://people.mozilla.com/~jmuizelaar/v8-flash.html>, I get a score of 2134 with Flash vs 11796 in Chrome. At least on this benchmark, it looks like V8 is a worthy competitor.

</comment><comment><USER24> I think this has to do with large companies resenting the fact open source developers spend their time making a free eco system better instead of improving their own frameworks for free.

I understand that JavaScript has its limitations, and Google tried to address this with their own language Dart. But this boils down to, you have a 100 billion dollar company serving 1 billion searches a day so you have different scalability issues than I do. But that's not my problem. With the current technologies like Node, MongoDB, Reids, etc… I can build a 1 billion dollar startup without the same scalability issues that a 100 billion dollar company has.

I would be quite happy to have a these scalability issues once I have a 100 billion dollar company then it will be my problem. But until then, getting a start-up up and running is ridiculously hard, the last thing I need is companies generating truckloads of cash putting their development issues on to open source developers.

</comment><comment><USER25> Yes, a typed language has a speed advantage over an untyped language, and if the argument is "which language executes faster", ActionScript will win. But this post declares that JavaScript is not a "worthy competitor" to ActionScript, completely ignoring all the advantages JavaScript has that explain why its usage eclipses that of ActionScript.

</comment><comment><USER26> Adobe yet again not getting it?

I realize that one person does not the voice of Adobe make, but I would have thought that he would realize that Javascript is very often not used in isolation, and more often than not as part of a large suite of technologies (Databases, network infrastructure, backend code - if not JS).

<comment><USER19> I think he's talking about using Javascript in flash's tradition role, i.e web games and interactive content.

<comment><USER27> I was going to comment, if Tamarin is so great, why haven't you integrated it into the browsers? But in doing my due diligence, I realized that Adobe did give the code to Mozilla for exactly that.

So this is actually about the language beyond Flash.

<comment><USER28> Wikipedia:

"The project to integrate Tamarin and SpiderMonkey was called "ActionMonkey",[6] but was canceled in 2008[7] because Tamarin's interpreter turned out to be slower than SpiderMonkey."

Ironically, it was too slow :P

</comment></comment></comment></comment><comment><USER29> So... Adobe is arguing that nobody will ever figure out how to put a better compiler in front of JavaScript under any circumstances, so we have to pack it in now?

I realize current JIT sucks in many ways, but seriously... claiming that "we can put this compiler in front of our stuff and since the other guys can never, never figure out how to compile first, we will win forever" isn't just stupid. It seems _willfully_ stupid.

Like, what about the second and successive times you run a given page's JavaScript, like if the page were in cache. Are they certain that open source's brain trust can never figure out how to compile that ahead of time?

Really?

<comment><USER28> Not knowing ActionScript, the point seems to boil down to no more than "statically typed languages will always be faster than dynamic ones". This is true no matter what, "open source brain" can't fix that.

However, one could make the same argument for C++: Why Python is not a worthy competitor. Sounds silly? It is, just like the original post.

<comment><USER30> > However, one could make the same argument for C++: Why Python is not a > worthy competitor. Sounds silly? It is, just like the original post.

Not quite. Nobody claims that python will completely eliminate the need for C++, but there are people claiming that JS will replace flash.

</comment></comment></comment><comment><USER31> Disappointingly trivial post:

1) I don't know a single person that would seriously argue that dynamically typed languages can perform better than their statically typed cousins.

2) As we all know, programming is the art of making tradeoff. One common pair is ease of writing vs. performance...

3) I think Adobe should be more worried about making a flash player/plugin I can't use to warm my hands by playing video after I come back from lunch.

<comment><USER32> I wouldn't be so sure about 1). JIT compilers can _in principle_ beat AOT by taking account of runtime profiling which AOT compilers have to make guesses at. I don't know how much (if any) of this V8 does, but it's a _hell_ of a leap to go from "static system 'a' beats dynamic system 'b'" to "all static systems of type 'A' will inevitably beat dynamic systems of type 'B'".

</comment></comment><comment><USER33> Is this an official Adobe communication or just some guy who will be packing his desk later today?

<comment><USER34> hahaha, exactly.

</comment></comment><comment><USER35> I want to see the benchmarks and the tests used...

</comment><comment><USER36> Pointless article, JS is not competing with ActionScript in the way that the author compares it.

Most of the time your app will probably be slow because of the DOM interactions, not because of your JavaScript, most time is usually spent in the rendering and fetching stuff from the network.

To give a better viewpoint: You won't write a database engine in Ruby or PHP, you will write it in C, C++, Java, but you will use PHP/Ruby to interact with it.

We have low level programming and high level programming for these distinct purposes. I am sure that if you won't write something in JavaScript you will probably not write it in ActionScript either.

</comment><comment><USER37> V8 is the catalyst, but it's only a small part of the bad news for Adobe.

There are many horses in the Javascript optimisation race. Chrome is the faraway leader, but all major browsers have delivered large improvements in Javascript performance over the past few years. Actionscript has hardly improved in five years.

<http://iq12.com/blog/as3-benchmark/>

</comment><comment><USER38> The argument in the article is true but this applies to any AOT language not just actionscript. A look at two popular 'alternatives' are native client and a vm in this instance serve two separate issues: sandboxing and standardization / interoperability. The issue with the latter is standardizing a bytecode would be complicated and a candidate could possibly be the parrot vm.

</comment><comment><USER39> I'm surprised noone has mentioned HaXe[1] : Which is an open source Actionscript-like language, with types (if you want them), which can compile down to .SWF, .JS, .CPP or even .PHP. All with an open source tool-chain.

[1] : <http://haxe.org/doc/intro>

</comment><comment><USER40> In other news, cars are faster than trucks, so clearly there is no valid reason to drive a truck.

</comment><comment><USER41> Entertaining, given how bad the Flash toolchain is: I'd have to be in a very bad performance spot to consider giving up a stable, functioning debugger, real text editor, usable tools and high quality APIs.

</comment><comment><USER42> This screams "Innovator's Dilemma" to me for some reason.

</comment><comment><USER40> That's nice, except I uninstalled Flash on my machine. It has an abysmal security history and I just don't need it that much.

</comment><comment><USER43> When I saw the domain name I was expecting some juvenile propaganda, rather than serious analysis. I was not disappointed.

</comment><comment><USER44> If Flash weren't a pile of shit. Adobe might have a leg to stand on.

That's a big if.

</comment><comment><USER45> Oh, so _now_ Adobe cares about performance.

</comment><comment><USER46> While we're at it, can the Adobe folks explain to the rest of the world when Flash is going to suck less? I mean really. Don't care about the on paper gibberish.

</comment><comment><USER47> Oh, I guess all the JS devs who work in the language every day didn't get the memo.

But in all seriousness, who couldn't have guessed that there would be some Flash/Actionscript dead-enders? Incredibly unsurprising that this was posted on adobe dot com.

<comment><USER48> I work with Javascript everyday.

And I hate it. It is broken as a language (var hoisting, this can mean pretty much whatever you want it to, no types, not even a good damm s32int).

But it works on all platforms and so it will always beat Flash.

<comment><USER49> Agreed that var hoisting can be tricky before you encounter a situation where it break something. (I suspect this happens to most JS devs at some point. Certainly has to me!)

However, what's wrong with not having types? Sounds like you're just not a fan of dynamic languages since this isn't a JS-specific issue.

<comment><USER48> I am a fan of typeless languages for small project and build files. But js takes the cake because it doesn't even distinguish between ints and floats.

</comment></comment></comment></comment><comment><USER50> Yet they bought phonegap anyway..ah huh sure ..

</comment><comment><USER51> Code or STFU.

</comment><comment><USER52> A strawman argument by an Adobe shill. Javascript and V8 aren't competition because they're faster, they're worthy competition because they're fast enough for most applications.

</comment><comment><USER52> I just looked up the author. Here's his Linkedin <http://www.linkedin.com/in/achaudhuri>

_July 2010 – Present (1 year 7 months) specification, design, and implementation of ActionScript_

Well, that explains a lot now, doesn't it?</comment>