Show HN: Building websites from Sketch using deep learning – public launch - <AUTHOR> https://zecoda.com/product <comment><AUTHOR> Founder here, again [1]. In August I've shared a side project that partially converted Sketch files into front-end code with the help of deep learning. Because of the feedback I got here and the number of early access requests I decided to open a private Beta in September.

It was the best decision I've ever made. In the last 3 months I found too many bugs and had incorrect assumptions. But learned so much because of all manual validation required to deliver projects. I now understand better my target market. Most importantly I've learned from actual paying customers [2].

We still don't have the whole process 100% automated though. We are delivering projects, on average, within 48 hours (too much time IMHO). Our goal is to decrease the delivery time for 12 hours in the next quarter. To achieve this we need more training data and a better human validation workflow.

Because we have more under control - but really far from knowing it all - <USER2> are ready to launch publicly. Zecoda it's a payed product because:

\- We still have human validation

\- We are solving a real world problem that has intrinsic value

\- We are in the business of making our customers happy and will never ship bad code

What we guarantee is that, if you are unhappy with the results, we'll refund you. Hopefully we'll be able to open a free tier in the future. Just need to reduce human verification to the minimum.

I'd love to hear your feedback and questions. This time you can actual try it :)

We can be more productive without repetitive tasks.

//

Sign up: [https://zecoda.com/register](https://zecoda.com/register)

Demo: [https://zecoda.com/#demo](https://zecoda.com/#demo)

Follow our journey: [https://twitter.com/zecodahq](https://twitter.com/zecodahq)

[1] [https://news.ycombinator.com/item?id=20624140](https://news.ycombinator.com/item?id=20624140)

[2] [https://zecoda.com/#customers](https://zecoda.com/#customers)

PS - Have a great Thanksgiving everybody!

<comment><USER3> Just playing devil`s advocate here, in the demo video :

1) Part 1 : You upload the file to the application and say we will run AI in background and a human verifies the file hence it will take time.

2) Part 2 : The code gets generated and you carry on from that point .

The problem is the time on your laptop for second part is 4:41pm and time shown on laptop for first part is 4:54 pm.

So it looks like you had the code before you uploaded the file.

I understand this might be for demo but gives wrong impression to people.

<comment><AUTHOR> Thanks for the heads up. Will definitely work on an examples page.

</comment></comment></comment><comment><USER4> Would be great if there was a section showing some sample example sites. That was the first thing I was looking for and it seems like an omission on the frontpage.

<comment><USER5> yes, specifically the code it generates. I realize theres human intervention, but on average what is the output.

<comment><AUTHOR> Thanks for reinforcing the importance of this feature! :) Just added it to our top priorities.

<comment><USER6> Excellent!

I am looking forward to this too.

</comment></comment></comment></comment><comment><USER7> I am skeptical with what people is calling 'AI' this days. I was expecting to see the generated code before subscription, there is a lot of sass that clain they have AI, but is only a bunch of if's and people 'helping the code'

<comment><USER8> You're being overly harsh. Sometimes there's also an else.

<comment><AUTHOR> Or even an if else.

</comment></comment></comment><comment><USER9> Why only a subscription based payment model ?

If I only want to 'convert' one sketch is there an option ?

Or do I have to process my 1 sketch in lets say your turnaround time is 1 week, then cancel my subscription ?

<comment><AUTHOR> That's a great question. Why not a 'per usage' model? We went for subscription because we learned, from our Beta, that our customers convert an average of 3 artboards per month. It's a valid point though and we are open to reiterate on feedback.

<comment><USER10> I'm surprised by this observed usage pattern.

I would have expected a spike in usage upon initial signup representing initial bulk artboard conversion, followed by a lower steady-state usage for updates & iterations, with periodic annual/biannual spikes for major redesigns.

Technically your pricing model supports this — a customer would just buy "overages". But people often don't like paying both a baseline subscription plus overage fees, as it can feel like the service is punishing them for straying outside plan lines.

Have you looked into a "credit rollover" type pricing model, plus some kind of kickoff bonus? E.g. you get 5 artboard credits on signup, then accumulate 2 per month that you can use whenever you want. (This is the approach Audible uses, for example.)

Users would be able to top up their credits whenever they want, but are rewarded for deferring low-priority usage so their credits build up in anticipation of more important work. There's also the additional advantage of sunk-cost perceptions making users less likely to churn a service while they have credits in the bank, even if they can't envision exactly how they'd use them today.

<comment><AUTHOR> That's great feedback! I appreciate the detail suggestion. I'll definitely have a close look at this possibility. It makes sense. The only hesitation I have in giving credits is the direct cost I still have per project (because of the human validation layer).

<comment><USER11> I'd expect that you would make the getting two credits cost the same as the current subscription, so the total income is the same, it just lets users feel freer to not have to come up with new projects each month.

</comment></comment></comment></comment></comment><comment><USER12> This looks impressive, kudos. Definately a novelty from HN audience standpoint.

By why would I as typical customer care how an agency (who you are substituting) converts sketch to site? I want quality, good price, fast delivery. Everything else can be a black box.

Don't get me wrong, not criticizing your idea or business model, just the marketing angle.

<comment><AUTHOR> Exactly! You nailed it, our goal is to reduce the cost of Sketch to front-end code keeping the quality. We hope to reduce that cost with the help of AI. How can we improve our marketing angle then?

<comment><USER13> I had the same reaction... Is "AI" a selling point to your likely customers? Otherwise it might be worth de-emphasizing it. You could turn it around... "We have humans generate your front-end code assisted by AI so we can keep prices affordable". To me, if I read "we use AI to do X" I read it as "we've got some algorithms that do a crappy job of X but we sell it cheap".

<comment><AUTHOR> Interesting point you are making. Never thought about it that way. Will definitely think about it in detail because in the that's exactly our selling point: "generate your front-end code assisted by AI so we can keep prices affordable".

<comment><USER12> Of course you can leverage the uniqueness of the approach initially to get trials/pr (as you are doing here in HN), just that won't be sustainable as selling point.

</comment></comment></comment></comment></comment><comment><USER14> Looks interesting!

How do you generate the hover states, if they are not in the sketch file?

Do you have to structure the layers/components in a certain way, or do you use ML from pixel data?

Any plans for Figma/React?

<comment><AUTHOR> Yes, our goal is to have as much input and output tools as possible.

The hover state was indicated on the Sketch file with a pointer hand cursor. This decision was made by the human layer.

</comment></comment><comment><USER15> This looks a lot like a WYSIWYG editor, is that a fair description? e.g using ML in place of some deterministic, manually defined heuristics for code generation.

I can imagine how it might produce better results and code than the terrible WYSIWYG editors of the early 2000s. However I would be careful about how much you market with the term "AI", as it could create unrealistic expectations.

<comment><AUTHOR> It basically turns Sketch into a WYSIWYG editor, yes. Regarding the marketing angle, I agree. It has been a fairly common advice here; we'll review our approach to market.

</comment></comment><comment><USER16> I'm doing something similar-ish (not AI but attempting to allow people to "draw" their UI and convert to a constraint-based layout ie HTML/CSS). It seems to me that the fundamental issue is there's no explicit information as to which edges of which nodes are meant to be constrained to which other edges. Is this box meant to be fixed-width, or stretch with its container?

How are you addressing this issue? I could be missing something but it seems to me that you can only really generate these constraints using guesswork ("this left-edge is only 10px away from its parent so it's probably meant to be a padding") and that while that may work for the majority of cases, it couldn't be fully automated as you're essentially guessing at user intents that have not been made explicit.

Either way I'm supportive of the goal - I think this could be a great product if you can either fix that issue or make it so it doesn't matter (with human corrections or additional inputs from the user or something like that).

<comment><AUTHOR> Good point. Our algorithm obviously has to make decisions. Sometimes it's right, sometimes absolutely wrong. However the goal is to output a legible and workable front-end code.

<comment><USER16> that's great, it would definitely reduce the amount of time I have to spent implementing sketch files. Do you have support for slicing sub-sections of a sketch file? As I work on long-lived products in my contracting work, I'm often implementing features that have been added as new UI to existing sketch designs.

<comment><AUTHOR> Not yet. It's on our backlog though. Totally agree that's an important feature to add.

</comment></comment></comment></comment><comment><USER17> Products like this are why I got out of FE dev. The overwhelming majority of what most FE devs do can and will be automated.

Stringing together various API's to match a sketch file and integrate with a backend is a task to be automated that should not require a full time developer making a 6 figure salary.

I am interested to see how this product is received, good luck to the team behind this.

<comment><AUTHOR> Thanks for the support!

</comment></comment><comment><USER18> Looks really useful.

Some small feedback: When I clicked "Front end created with Zecoda" I expected to learn about how your site is an example of how your program works well. For example, to see a side-by-side of the sketch file, rendered code, and raw html/css/js. Instead, I got a signup prompt with no offer of what I'd get in return (sign in to see our site in our editor or something).

The message "Be happy, we are doing this for you" is grammatically awkward and sounds a little passive aggressive.

The acronym "IOHO" might be too causal, I think.

<comment><AUTHOR> Thanks so much for all your feedback. We are working on a examples page and we'll make the "Front end created with Zecoda" badge a link to that page.

<comment><USER18> Cool! If you're not planning to already, I'd suggest showing the code you produce on a "for developers" page. I'd want to know if for example the function/variable names are reasonable, and if in general it looks understandable and maintainable by a human.

<comment><AUTHOR> Working on it as we speak :)

</comment></comment></comment></comment><comment><USER19> Great idea and appreciate your efforts to action.

Q1: using sketch filesto convert it to code is a good idea. How scalable is your project at its current status to scale it to work for mock up images. In other words- how easy is for your software to convert an UX image to code. We would like to see some POCs.

<comment><AUTHOR> Our NN actually learn from images. However the Sketch file is essential to get texts and specific element styles. It's a good idea to explore though. Thanks!

</comment></comment><comment><USER20> So a few problems:

1\. No trial of any kind without subscribing (yes I know about the refund option).

2\. No way to contact support when logged in.

3\. No way to delete my account (it's 2019 people...)

Will certainly take another look when I can try without buying.

<comment><AUTHOR> All valid points you are making. Will definitely add 2 and 3 today. Thanks!

</comment></comment><comment><USER21> You can get someone on any of the freelancing sites to convert your design to HTML and even a WordPress site - at the cost of five bucks. For 30 bucks you also get a design. If you want quality the prices will go up exponentially though. But noone seem to care about quality /grumpy freelancer

</comment><comment><USER22> @johndamaia – your Zillow testimonial has "an" misspelt in "knock ant artboard"

<comment><AUTHOR> Thanks! It was a direct "copy paste" from the client quote. Will fix it later today.

</comment></comment><comment><USER23> Can it build complex forms too or is this just "the robot makes a squarespace website"?

<comment><AUTHOR> It doesn't send any data or have axios integrated. It will output the form (probably in Vue) for a developer on the client side to connect the dots with an API.

<comment><USER24> Building the form widget is the easy part, "connecting the dots" as you say is what takes 80% of the time and produces 99% of the bugs.

<comment><AUTHOR> Not sure I agree. From our own experience the boring and time consuming part is translating the specific design to front-end code. "Connecting the dots" is the essential and most important part, not necessarily what it takes more time.

<comment><USER24> I suppose if your use case is marketing sites or something similar. This doesn't match my experience at all.

<comment><USER25> Nah man, my sites are all very complex apps. Managing the UI is the complicated part, reading data from an api is relatively trivial.

<comment><USER24> There's more to building your UI than just implementing the design. Even if using this tool all the logic and state management you have to do by yourself.

Putting together the form is the easy part, especially in a large application. You implement your inputs once and re-use them across the app. It's managing the UX and business logic that's hard.

<comment><USER25> Well I haven't used the tool but I kinda just assumed they would do a good job at this. If all they do is implement each page independently of each other and there's not vue best practices then it's really useless. But I assume it would handle the complexity of the UI.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> The demo video was quite small on my screen, and I couldn't make it go fullscreen. Might be good to allow fullscreen.

I also second the top comment: some demos would be necessary to prove the value of the app, I think

<comment><AUTHOR> We are using Youtube embed - they control the player. Which device were you using?

<comment><USER27> YouTube embeds have an option to allow fullscreen (allowfullscreen="true"). You didn't turn it on.

<comment><AUTHOR> Already made the change, thanks!

</comment></comment></comment></comment><comment><USER28> This is so cool. How did you build this? How did you train your net? Does it even use a net? I'd love to know about how this works!

<comment><AUTHOR> We trained a NN to learn UI elements like buttons, inputs, navbar, etc. With that information we can grab the Sketch elements and build the correct UI in the correct coordinates.

</comment></comment><comment><USER29> all AI is meat based

<comment><AUTHOR> I agree. We are in a stage where human validation is essential to guarantee a fair output. From "Amazon Go" to "Unbabel", all have "meat" behind it.

</comment></comment><comment><USER30> Did you watch the good place? xD

</comment><comment><USER31> nice to see more of these snake oil/fake SaaS by indie developers, enjoy the easy money while it lasts, because it won't for so long, or will it?

<comment><USER32> You can't post like this here. It breaks not only the site guidelines ([https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)) but also the Show HN rules: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html).

You've been posting comments that break the site guidelines at an alarming rate. We've asked you several times to stop. Since you keep doing it. I've banned this account. If you don't want to be banned, you're welcome to email email@example.com and give us reason to believe that you'll follow the rules in the future.</comment></comment>


Black-Scholes: The maths formula linked to the financial crash - <AUTHOR> http://www.bbc.co.uk/news/magazine-17866646 <comment><USER5> This article is deeply flawed, primarily because it parrots the common misconception leveled against the formula, and options market by association (by none other than Taleb himself - who obviously knows better but prefers to act like a self-important bafoon).

Here is the crux of this misconception - that traders assume a Gaussian (ie Normal) distribution of events, while the world is far from "normal". THIS IS ABSOLUTELY WRONG. Traders and investors know that the world is full of "Fat Tails" and price the options accordingly. This is what's known as the Volatility Smile [1]

[1] <http://en.wikipedia.org/wiki/Volatility_smile>

Moreover - the formula is not used to predict anything. It simply converts a trader's expectations of future events (ie volatility) into dollar figures - price of the option. So the sentence "Black-Scholes changed the culture of Wall Street, from a place where people traded based on common sense, experience and intuition, to a place where the computer said yes or no" - <USER2> absolute nonsense. People still trade based on common sense and intuition - <USER3> is merely a way to convert views in numerical figures.

<comment><USER6> The Normal distribution is part of the parametric derivation of the Black- Scholes pricing model [1]. It really does seem to be part of the model's key assumptions.

Can you expand on how the Volatility Smile demonstrates that traders model fat tails in their options pricing strategies. It wasn't clear to me from the wiki page you linked.

[1] <http://en.wikipedia.org/wiki/Black-Scholes#Notation>

<comment><USER5> Sure, I'll try. Here is an example:

Assume that you want to buy an option on Apple stock - 3 months in the future. Assume that price today is $500. If you want to buy an option with strike=500, you will pay 50 vol (BS as a formula will just convert the price in vol terms into a dollar cash price). But - if you want to buy an option struck at 400 - you might pay 75 vol. And if you want a 300 strike - it will be 100 vol.

As you see, volatility will RISE the further you move away from spot price (ie where it is today). So while BS calculation assumes constant volatility to convert vol to dollars, traders always ask for higher vol, as you move out to less likely scenarios. That is how they deal with the world being non-normal. It really is options 101 - so any writer who talks about BS assuming Gaussian probabilities is either lying or doesn't know anything about the subject.

<comment><USER7> The most common derivation of Black-Scholes absolutely does assume a standard normal distribution. There are other models that don't (i.e., Mandelbrot tried to get people to use Levy distributions, and a lot of newer models are built around martingale theory), and traders have adopted rules-of-thumb that pull prices out of line with what BS says they should be, but it's certainly not the case that anyone who speaks of BS assuming Gaussians is lying or speaking from ignorance.

<comment><USER5> Uggh, no. Let me try and explain. BS is _not_ used as a model that explains how the world works.

It's just a formula to _convert_ volatility to a dollar price of an option. But the actual _vol surface_ that people use is anything but Gaussian. So the job of the trader is to construct a vol surface. However in order for 2 people to trade an option, they have to agree to a cash price - which is when BS is used. But the entire trading universe revolves around _vol surfaces_.

Think of it as making a painting. BS is just a single paint pigment - <USER4> the painter will take 20 pigments and mix them up to produce millions of colours. So to accuse those who use BS formula of assuming Gaussian probability distribution is akin to saying that painters use one color to paint.

</comment></comment></comment></comment></comment><comment><USER7> If you ignore the absurdly stupid title, this is actually worth a quick read. It's excerpts from interviews with Myron Scholes and Ian Stewart woven into an oversimplified but not completely awful overview of Black-Scholes and its impact.

If the question interests you, I recommend _An Engine, Not a Camera_ by Donald MacKenzie. It goes into great detail about the history of Black-Scholes, its application in options trading, and how it (or, rather, financial modeling in general) tied into the 1987 crash and the failure of LTCM. I have a small writeup about it at <http://jasonfager.com/1080-an-engine-not-a-camera/>

<comment><USER8> Another thumbs up for "An Engine, Not A Camera." A great book on the philosophy of financial modeling and how models influence the markets (the "engine"), rather than providing static snapshots of information (the "camera").

</comment></comment><comment><USER9> Here is an interesting take on the formula from The Black Swan by Nassim Taleb:

> Things got a lot worse in 1997. The Swedish academy gave another round of > Gaussian-based Nobel Prizes to Myron Scholes and Robert C. Merton, who had > improved on an old mathematical formula and made it compatible with the > existing grand Gaussian general financial equilibrium theories—hence > acceptable to the economics establishment. The formula was now "useable." It > had a list of long forgotten "precursors," among whom was the mathematician > and gambler Ed Thorp, who had authored the bestselling Beat the Dealer, > about how to get ahead in blackjack, but somehow people believe that Scholes > and Merton invented it, when in fact they just made it acceptable. The > formula was my bread and butter. Traders, bottom-up people, know its > wrinkles better than academics by dint of spending their nights worrying > about their risks, except that few of them could express their ideas in > technical terms, so I felt I was representing them. Scholes and Merton made > the formula dependent on the Gaussian, but their "precursors" subjected it > to no such restriction. /.../

> And the option formula went on bearing the name Black-Scholes-Merton, > instead of reverting to its true owners, Louis Bachelier, Ed Thorp, and > others.

<comment><USER10> Did Ed Thorp ever publish his formula? I'm flipping through his book Beat the Market now, and so far I've only seen two rules of thumb for pricing an option, which would only be useful for identifying the most absurdly mispriced options.

An option should be worth at least its intrinsic value, I agree. But how much more? You don't get Nobel prizes for stating something that's common sense.

<comment><USER9>
       You don't get Nobel prizes for stating something that's common sense.

True. You get Nobel prize for assuming that returns follow Normal distribution, which goes against common sense.

</comment></comment></comment><comment><USER11> At least now, title does not go as far as claiming that this is formula that _caused_ the crash, unlike this sensationalist piece[1]. The other popular formula to pick on is Li's Gaussian Copula [2] that did not address tail risks and dynamics of assets' co-dependence.

The important thing to remember is that finance is not physics and any model of reality is just that - model. As long as model's assumptions are close to reality, model works fine. It is failure to understand limitations or when assumptions do not hold any more that led to crash.

Actually the over-reliance of quants on models like Black-Scholes or Gaussian copula is a testament to how well these models work (or should I say worked?) for specific market conditions.

[1] [http://www.guardian.co.uk/science/2012/feb/12/black- scholes-...](http://www.guardian.co.uk/science/2012/feb/12/black-scholes- equation-credit-crunch)

[2] [http://www.wired.com/techbiz/it/magazine/17-03/wp_quant?curr...](http://www.wired.com/techbiz/it/magazine/17-03/wp_quant?currentPage=all)

<comment><USER12> > The important thing to remember is that finance is not physics and any model > of reality is just that - model.

Side remark: this is true of physics too, only the models are better tested and we are better at understanding their scope of application.

<comment><USER13> But physics doesn't pay attention to our models and intentionally change its behavior to stymie us. The financial market does, since financial modelling is the recursive introspective study of its own modelling process.

</comment></comment></comment><comment><USER14> 1\. only use numbers based on models you fully understand

2\. always remember: all models are wrong, (but some of them are usefull.)

p.s.: does soembody know a really good book about system modelling? i`m searching for one.

<comment><USER15> Not what you asked but you might find it very interesting: <https://class.coursera.org/pgm/auth/welcome>

<comment><USER14> thx, sadly i don't do video (there are readers and there are listeners in this world, i'm definitely a reader), but i'm giving here book a chance [http://www.amazon.com/Probabilistic-Graphical-Models- Computa...](http://www.amazon.com/Probabilistic-Graphical-Models-Computation- ebook/dp/B007CNRD62/ref=tmm_kin_title_0?ie=UTF8&m=AG56TWVU5XWC2)

<comment><USER15> I'm more of a reader too, but these videos are very different. Give it a try to a non-introductory video. They have quizzes and you need to follow with the material and even do some coding.

</comment></comment></comment></comment><comment><USER16> This is a fairly sensationalist article. Misaligned incentives and poor risk management cause crashes, not formulas and models.

Every option trader I've ever met is 100% aware of the limitations of Black- Scholes and are not using it blindly to price options/complex derivatives.

Black-Scholes assumes returns are lognormally distributed. The market knows this not to be true and you can back out this fact from option prices. Inputs such as kurtosis and skew are used to determine a more accurate representation of returns.

</comment><comment><USER17> coming soon -- Compound interest: the maths formula linked to the financial crash

</comment><comment><USER18> Who blames their equation for the financial crash? Afaik, it's a tool to valuate options, not an algorithm to trade or valuate mortgages. The link is that it "caused investment banks to hire people who had quantitative or mathematical skills". Which is like blaming Marie Curie for the Fukishima disaster.

</comment><comment><USER19> One thing that is quite easy to forget:

A formula is a formula, it's a tool

It does not crash markets, people who misuse it are the ones who cause trouble.

<comment><USER20> "Guns don't kill people... people kill people"?? "But I'm pretty sure the gun, helps"

<comment><USER19> More or less

But I can have an accident with a gun. The gun is a physical, tangible instrument for delivering damage.

You don't see people getting killed directly by formulas.

Also, you are responsible for feeding the parameters in the formula. The formula doesn't interpret or act in the values it provided.

</comment></comment></comment><comment><USER21> It's not a good article. Apparently the point is that Black-Scholes assigns too low a probability to large price swings.

Even if true, I don't know what it has to do with this particular financial crisis, and the article doesn't speak to that either.

</comment><comment><USER22> This is so retarded.

Everyone has known for decades that these models (Black Scholes / Gaussian Copula) are wildly inaccurate in the tails. where the real risks live. They are roughly accurate on quiet days. Mandelbrot has been publishing on this since the 1960s! Anyone who pretends to believe these models is running a scam of some kind.

It is true that the GC played a minor role in the recent crisis but Black Scholes did not. See below for details.

The factors in the 2007-2012 crisis:

1\. Fraudulent lending practices and falsified loan applications.

2\. Excessive borrowings by households fueled by the Fed keeping interest rates too low for too long.

3\. Belief that present trends would continue forever and house prices would continue to the moon.

4\. Greed blinded people to the risks they were taking.

5\. Lax to nonexistent regulation which allowed banks and related organizations to leverage to insane levels. It also allowed companies like AIG to sell insurance that they could not pay off on.

6\. Risks were ignored due to perceived government guarantees (Fannie Mae and her ilk).

7\. Fraudulently selling subprime toxic garbage as AAA securities. This is where the Gaussian Copula came in. Given known wrong and bogus assumptions (eg that house prices would never fall across the whole USA), it allowed the investment banks to pretend that the top tiers of the subprime securities were AAA ie secure. Internal emails showed they knew they were not really AAA. However the GC was only the vehicle; the underlying problem was fraudulent and criminal intent.

8\. Rating agencies were paid large sums of money to rate the toxic waste as AAA. They either knew or did not care that the securities were toxic waste as long as they got the cash.

9\. Pension funds and other naive investors believed that the rating agencies and investment banks were not lying when they said the AAA-rated securities were OK.

10\. More recently we have seen the crisis in Europe which is the result of the failure to rein in housing bubbles caused by too-loose credit, and by governments which borrowed more than they could afford to pay back, and which made commitments that they could never fulfill (eg excessive pensions).

BS played a role in the near meltdown in 1998 when LTCM went down, and also in the 1987 stock market crash.

In both cases idiots pushed the models outside their sphere of validity. LTCM was leveraged to the hilt and assumed that short term historical correlations would continue to prevail. A cursory examination of history would show this is not the case.

In 1987 a technique called "portfolio insurance" was invented which supposedly allowed the user to simulate a protective "put option" at no cost. Portfolio insurance required selling stocks when the market fell. The BS model assumes infinite liquidity and no price jumps and if these are true PI should work. Again these are not valid assumptions and when the technique was implemented on the overvalued October 1987 market it accelerated and intensified the crash.

Even in physics most models are inaccurate outside a certain range of validity. It requires a degree of honesty and intellectual integrity to refrain from using them when they are not valid. Eg you cannot use Newtonian mechanics at 99.999% of the speed of light.

TL;DR this was not a mathematical mistake - it was fraud.</comment>


Deaths per unit of energy for various sources - <AUTHOR> http://www-958.ibm.com/software/data/cognos/manyeyes/visualizations/2e5d4dcc4fb511e0ae0c000255111976/comments/2e70ae944fb511e0ae0c000255111976 <comment><USER2> The sources look good [1] In particular, the deaths as a result of hydroelectric power caught some catastrophic failures. Dams are very, very dangerous constructions, and have a failure mode that makes a nuclear plant look safe by comparison. Just one major Hydroelectric Dam [2], Bangiao, was responsible for on the order of 50,000 deaths related directly to the Dam Failure.

[1] [http://nextbigfuture.com/2011/03/deaths-per-twh-by-energy- so...](http://nextbigfuture.com/2011/03/deaths-per-twh-by-energy-source.html)

[2] <http://en.wikipedia.org/wiki/Banqiao_Dam>

<comment><USER3> If 50,000 people were to die from a nuclear incident, a large portion of the public would absolutely lose their minds and _insist_ that a nuclear reactor never again be built on the planet.

50,000 deaths resulting from <choose any other technology> however, is just an unfortunate incident. Hundreds of people will die year after year mining coal with nary a whimper of complaint, but we will hear about people sufferring from thyroid cancer 20 years after Chernobyl until the end of time.

(Sorry, a tad snarky....but also very true, no?)

<comment><USER4> If Chernobyl had been a dam burst incident, people would be living in Pripyat right now.

What if a nuclear disaster like that happened next to say, Philadelphia, and left the area uninhabitable for 10,000 years?

<comment><USER5> Haven't people been visiting Pripyat and finding it to be habitable to a lot of species of life? It won't be a wasteland for 10,000 years. And Chernobyl was so pooring designed it is not analagous to everything else (as was the damn that killed 50,000 people).

<comment><USER6> Are you joking? It's only 'habitable' in the sense that wildlife doesn't drop dead the moment it enters the exclusion zone. The animals are still receiving substantial amounts of radiation, and will continue to suffer for decades. The worst areas will be dangerous for centuries.

<comment><USER7> Towns like Picher, Oklahoma, will still be toxic when the sun goes out.

Radioactive Ceasium and Strontium are a pain for a few decades - lead, mercury and cadmium are for ever.

<comment><USER6> Non-sequitor. Just because something else is bad doesn't make this situation any better.

<comment><USER7> Oh my god they had a nuclear accident in Japan - we must shut down our nuclear reactors and instead pump out many millions of tons of dangerous radioisotopes and chemical poisons from new coal plants instead.

It's standard knee jerk procedure. We had a rail accident (the first in 10years) so the reaction was to close a bunch of inter city lines for months while they checked everything. Where did all those extra travellers go? onto the roads!

I hope the government doesn't hear about the problems with Toyota in america - they would then ban ABS and give everybody Tiger tanks to commute on.

<comment><USER4> I think most people who are opposed to nuclear are hoping governments and industry will seriously pursue more sustainable and non-toxic sources of power, not coal.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I feel like this line of reasoning misses the point a bit. Nuclear waste is dangerous for a very very long time, while deaths from these other sources are front loaded. When can people move back to chernobyl? If we have significant radiation exposure in japan, how long will that land be uninhabitable? Nuclear waste we create today is dangerous for how long?

<comment><USER9> Unless you have a negative discount rate, a few (hypothetical) deaths in the distant future is less bad than a few deaths now.

People currently live in the Chernobyl exclusion zone, 24 years later:

<http://www.spiegel.de/international/0,1518,412954,00.html>

There was significant radiation exposure in Japan a while back. This is what it looks like today:

<http://en.wikipedia.org/wiki/File:HiroshimaNight.jpg>

<http://en.wikipedia.org/wiki/File:Nagasaki_C1414.jpg>

<comment><USER8> couldn't it be a lot of hypothetical deaths? I also fail to see how dumping our waste on generations to come for our own selfish desires is less bad. I think it's less responsible to expect someone else to bear the risks in the future for a reward I want now. Maybe I'm not looking at this like a banker ;)

My default position isn't anti-nuclear, but I find a lot of the arguments and reasoning on the pro-nuclear side to be less than convincing, and in some cases disingenuous. Nuclear seems safer than coal, but the knee jerk reaction on this site from pro-nuclear people isn't helping that cause. Go read the comments on the posts the day after the earthquake, most of them said "everything is fine, nothing bad can possibly happen". Turns out that wasn't true.

<comment><USER10> > I also fail to see how dumping our waste on generations to come for our own > selfish desires is less bad.

You're assuming that just because we consider it waste, they will too. Personally, I'm expecting that at some point some use will be found for the 'waste' -- maybe highly efficient reprocessing or materials for low-radiation (think 'easily traced') medical nanobots -- at which point future generations will thank us profusely for generating such convenient stockpiles of the stuff.

<comment><USER8> I'll begin dumping all of my garbage on your lawn. I expect at some point you will find a use for this "waste". At some point you will thank me profusely.

</comment></comment></comment></comment></comment><comment><USER11> The thousands of children (now adults) near Chernobyl with thyroid cancer don't show up in these stats, since they're not all dead.

Doesn't necessarily change the conclusions but worth noting.

<comment><USER2> From the sources:

"But what about Chernobyl ? The World Health Organization study in 2005 indicated that 50 people died to that point as a direct result of Chernobyl. 4000 people may eventually die earlier as a result of Chernobyl, but those deaths would be more than 20 years after the fact and the cause and effect becomes more tenuous.

He explains that there have been 4000 cases of thyroid cancer, mainly in children, but that except for nine deaths, all of them have recovered. "Otherwise, the team of international experts found no evidence for any increases in the incidence of leukemia and cancer among affected residents.""

<comment><USER11> My point is that you or your child getting thyroid cancer, even if you or she recovers, is a pretty horrific outcome, and might deserve to be considered somehow -- not just fatalities.

<comment><USER12> that's what nuclear fanatics here don't seem to get.

as I argued in other thread about the original numbers, what matters aren't direct deaths attributed to one or the other energy source.

what matters (to me at least) is how different energy sources affect our _quality of life_. I suspect nuclear isn't the worst offender here, but it isn't all butterflies and roses either.

For the record: I am _responsible_ nuclear fission proponent.

<comment><USER13> Wikipedia[1] cites a claim that France (which generates on the order of 80% of it's power from Nuclear) has the cleanest air of any industrialised nation, due in large part to the lack of fossil fuel burning plants.

I for one think that's a reasonable trade to make for a few nuclear waste dump designated areas being radioactive until we can get some breeder reactors or similar to break them down more quickly.

[1] <http://en.wikipedia.org/wiki/Nuclear_power>

<comment><USER12> really? Some better [citation needed].

2002:

 _Scandinavia and the Baltic countries had the cleanest air in Europe this summer while Greece, France and Italy faced the worst smog levels, said the European Environment Agency (EEA)._

<http://www.am.gov.lv/en/?id=574>

And BTW, I am fully in favor of replacing coal plants with nuclear.

<comment><USER14> Scandinavia is mostly driven by nuclear and hydro power. So the point still stands.

<comment><USER12> Hydro - yes. Nuclear - no.

Denmark and Norway - no nuclear.

Sweden - 45% nuclear.

Finland - 30% nuclear.

<comment><USER14> Uh, you're saying nuclear no, but then nuclear 45% of Sweden and 30% of Finland, so you must mean nuclear yes.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> So basically, according to this graph, coal, oil and natural gas cause way more deaths per unit of energy produced than other energy sources, and notably, nuclear energy is by far the least dangerous.

That's interesting, if it's true.

<comment><USER16> Same reason people are much more afraid to fly than drive, despite statistics- We're not scared of dying so much as dying in a catastrophe. Also notice that natural gas is especially low, even though everyone who's ever had gas heat has imagined their house exploding.

I'm pro-nuclear myself, but you could argue that these stats are somewhat misleading, since nuclear deaths would tend to come in bunches and the fears are based on what could happen, not what has happened.

You could also conclude that nuclear weapons are extremely safe to have around since they haven't killed anyone for 65 years.

<comment><USER17> If you compare flying vs. car driving upon the live-time spent with this activities, then 2h flying is much more dangerous than 2 hour car driving. Usually this is compared by distinance, but this is wrong. For example last year I spent my holiday nearby driving by car, this year maybe I am going to fly to a distant place utilizing the same transport time. The flying holiday is far more dangerous than the driving one. I do never decide between car and plane for a given goal, therefore the risk relation to the distance is wrong.

<comment><USER18> Nope. Even when you count per hours, planes remains vastly safer than car -- more than 4 times safer.

Deaths per billion hours Bus: 11.1 Rail: 30 Air: 30.8 Water: 50 Van: 60 Car: 130 Foot: 220 Bicycle: 550 Motorcycle: 4840

Deaths per billion kilometres Air: 0.05 Bus: 0.4 Rail: 0.6 Van: 1.2 Water: 2.6 Car: 3.1 Bicycle: 44.6 Foot: 54.2 Motorcycle: 108.9

Reference:

[http://en.wikipedia.org/wiki/Air_safety#Accidents_and_incide...](http://en.wikipedia.org/wiki/Air_safety#Accidents_and_incidents)

<comment><USER17> This of course depends on the sources. Mine are the official Austrian statistics. With your sources bus is still more than 2 times safer per hour.

</comment></comment></comment></comment></comment><comment><USER19> Wait, are you trying persuade us with facts?

Airplanes are the safest way to travel by far. That doesn't prevent people from stubbornly refusing to fly (taking very unsafe road trips instead), it doesn't prevent panic attacks in the air, and it doesn't stop governments wasting billions on security checkpoint theater.

God speed, my friend, I sincerely hope the facts will make a difference.

<comment><USER20> _Airplanes are the safest way to travel by far_

Yes and no. That depends on how you measure. The typical statistic used (deaths per man-kilometer) favors flying a bit.

For example, the space shuttle is safe, according to that metric (guesstimate: 60 shuttle flights for every crash => over a year in space for every crash, 16 times round earth a day => 60000 revolutions * 40k km => 2*10^9 man km per death)

According to <http://en.wikipedia.org/wiki/Air_safety#Statistics> making one plane ride is riskier than taking a bus once.

Moreover, taking of and landing are the high-risk parts of flying. So, I would expect that flying would score worse than that when people starte making shorter flights.

<comment><USER21> I redo the space shuttle risk using the data from [http://en.wikipedia.org/wiki/List_of_space_shuttle_missions#...](http://en.wikipedia.org/wiki/List_of_space_shuttle_missions#Flight_statistics)

      Total Orbits: ~20K
      Orbits Length: ~40K Km
      Crashes: 2
      (Assuming same number of crew in each flight.)
      Risk: 20K * 40K Km / 2 = 4*10^8 man Km per death
      Or: 2.5 deaths / billon Km

So using the Risk/Km criteria the space shuttle is as safe as (water)ships, safer than cars and riskier than trains.

</comment></comment></comment><comment><USER22> It should be pointed out that there will never be another Chernobyl. It was a perfect intersection of criminally inadequate design, early-adopter naivete, incompetence, and Murphy's Law.

In these discussions, bringing up Three Mile Island is fair game, but Chernobyl is not a realistic parallel.

<comment><USER23> Chernobyl: the nuclear disaster to end all nuclear disasters?

</comment></comment><comment><USER24> Illustrates again that people are afraid of what's scary, not what's likely to actually happen.

<comment><USER25> Reminds me of the "Stranger Danger" scare a while back. Teaching children to beware of strangers makes them safer from kidnappers, but less safe if they get lost or need help from a random adult for some reason. Guess which of these situations is more common.

</comment></comment><comment><USER26> I'd like to see the cost in $ per TWh as another column.

</comment><comment><USER27> I'm missing (or the article is missing) the timeline that the calculations are based on. Is that yearly? last year? last 5 years?

We have to take a significant time scale on any of these for it to be considered reliable. Though there may have been 0 deaths from nuclear last year, over a 10 year span, would that number be the same?

I believe nuclear can be safer over the long-run, but I'd like to see some more depth in these stats.

<comment><USER25> The nuclear calculations have a long timeline. They include mining deaths for plant construction and refueling, and one Chernobyl-scale event every 20 years or so. The numbers are explained in much more detail here:

[http://nextbigfuture.com/2011/03/deaths-per-twh-by-energy- so...](http://nextbigfuture.com/2011/03/deaths-per-twh-by-energy-source.html)

<comment><USER28> I read it as allowing for one of that scale every 45 years, the entire duration of data calculation, arriving at 0.037 deaths per TWh. There's no indication that more than one event of that scale is contemplated.

</comment></comment></comment><comment><USER29> a great part of the fear is that you can not see radioactivity harming you. Water I can see. Mining coal feels like it is within my control whether I engage in that activity or not.

<comment><USER30> This is the most common reasoning for people who fear nuclear power. They reason that they can't see where the danger (radiation) is so they can't know if they are in danger or not, whereas with an oil spill, a gas pipeline explosion, or an oil refinery event, they have visible boundaries to 'this area is bad' vs 'this area is probably still safe' (note its not of course, you can have odorless and invisible threats like CO but many of the failure modes are visible in a spectrum our unaided senses can detect)

I don't have a good answer for re-assuring these folks. (carrying a counter with them seems to be a non-starter, but perhaps a cell phone app would be ok)

</comment></comment><comment><USER31> The linked sited is an article that links to a blog post that doesn't really say exactly how they came up with their results, but provide some links (e.g. [http://manhaz.cyf.gov.pl/manhaz/strona_konferencja_EAE-2001/...](http://manhaz.cyf.gov.pl/manhaz/strona_konferencja_EAE-2001/15%20-%20Polenp~1.pdf)).

It sounds like they take into account deaths where coal air pollution was a contributing factor, but not deaths where radioactive fallout was a contributing factor, and they don't attribute global warming related deaths to fossil fuels.

They also don't take into account ongoing risks - some forms of energy present risks long after the energy has been harvested, so the numbers will continue to rise, while others don't).

I'd therefore take those results with a grain of salt.

</comment><comment><USER32> Also good to take into account is that Chernobyl and TMI and Fukushima are installations from the 1970's or early 1980's.

And even for those old birds the stats seem fairly favorable.

But as long as emotions fueled by scare-mongering have the upper hand, rationality and facts make no chance. So really widespread adoption of nuclear energy (be it fusion or fizzion - I'd be surprised if the public at large makes any distinction between them) is probably not going to happen for the near future. And that's a shame as it could be our ticket out of both a lot of environmental issues and socio-economic issues.

</comment><comment><USER33> Are they counting Iraq War deaths?

<comment><USER34> Didn't the war in Iraq reduce oil production from that country?

</comment></comment><comment><USER35> I can't find the crude death numbers in the article. It seems like there's a small chance that the number of deaths due to nuclear power in all of history could increase by a factor of 10 or more due to events in the next week or two, which would push it past rooftop solar energy, although it would still be nowhere near coal.

</comment><comment><USER36> I think we should also measure an average number of deaths caused by a single incident and the average number of deaths among strangers caused by a single incident. The incidents at nuclear plants are rare, but the consequences can be much more dangerous than from the other energy sources.

</comment><comment><USER37> One problem with this visualization is that it does not account for future deaths and less noticeable health effects caused by radioactive waste and accidents related to its storage. On the other hand, it also does not account for the same caused by oil and coal and other pollution.

</comment><comment><USER38> The deaths from solar appear to be from falls while installing roof-mounted systems; this would be primarily applicable to residential and small commercial solar systems, whereas most larger systems will tend to be ground- mounted and safer to construct.

<comment> Tuna-Fish This mostly serves to illustrate just how small the current solar install base is.

</comment></comment><comment><USER39> So natural gas is the safest?

It is same order of causalities as nuclear, albeit with dramatically less safety effort. One can only imagine how safe would it be if as much was spent for safety measures as with nuclear per TW.

</comment><comment><USER40> It's just a visualisation of [http://nextbigfuture.com/2011/03/deaths-per-twh- by-energy-so...](http://nextbigfuture.com/2011/03/deaths-per-twh-by-energy- source.html) figures from a couple of days ago, which I found highly dubious.

For example where are all the biomass deaths from? Why no figures for non- rooftop solar?

What does this "Hydroelectric power was found to to have a fatality rate of 0.10 per TWh (883 fatalities for every TW·yr) in the period 1969–1996" mean? How does spinning a turbine from dammed water cause death?

Ah ... further down the page "... Paul Gipe estimated ..." - so someones estimates without proper working or sources for death rates and such ...

I would love to see a well worked properly sourced analysis along these lines however.

<comment> Tuna-Fish Burning biomass causes high levels of particulate emissions, which are a very significant health risk (Burning firewood is the most important source of air pollution in much of the developing world).

Hydro is completely safe most of the time, but when a dam fails, it typically kills a lot of people really quickly.

It would be really hard to collect figures for non-rooftop solar -- simply because there is so little of it. (They would be very favorable.)

<comment><USER40> Biomass - comprehension error on my part, I thought that it was using dung in fermenters and like apparatus.

There seems to be enough solar farms to make the same sort of estimates as have been used in the article though.

I think what would be most helpful would actually be a comparison for a large country with similar safety standards across all industries looking at facilities over a fixed period. That would help, IMO, to rule out problems like people continuing with a hydro project even though the dam is cracked from the off ...

</comment></comment></comment><comment><USER41> What about all of the plants and animals killed from the various resources? Or the land and water that can no longer sustain life because of one disaster or another...

<comment><USER42> I'm not sure what you think this will prove, but if you're going to go this route it's going to make nuclear look even _better_. Much more confined mining operations, much smaller land use (something almost all "green" technologies are actually _terrible_ with, IIRC nuclear is the most power-per-acre you can get with current tech), waste goes to uninhabited areas anyhow (and if we were less stupid about it there wouldn't hardly be any), and take a quick Google at "pictures of Chernobyl" [1] and note how it isn't a radioactive wasteland in the style of Fallout or anything.

Very little land has actually been rendered "unable to sustain life"; I'm not sure it measures in anything more than a handful of acres. Hollywood movies and video games are not a good way to learn how nuclear power works.

[1]: <http://www.grcade.com/viewtopic.php?t=2217> \- note the greenery all the way up to the plant itself

<comment><USER41> It may make nuclear look better comparably, but it will make all of these (oil, coal, nuclear) look worse.

When all you factor into the cost is human life and money, you miss the bigger picture of how we're affecting what doesn't have a voice.

</comment></comment></comment><comment><USER43> flawed observation. true, nuclear accidents don't happen often but when they do you have to deal with immediate and long term effects. as far as I know, coal power plant accidents don't cause deformities for the next 2/3 generations. also I don't see the numbers on solar and wind.

</comment><comment><USER44> Why are you people advocating for nuclear power so much? Solar and wind power should be the future, and they're renewable. Don't you think that's a much better future? Sure they might not be very effective now, but a couple of decades down the road with some big investments (like in nuclear plants) it should be orders of magnitude more effective than it is now.

Of course, a country like USA will never back down from using nuclear plants because they need their byproducts to make nukes.

<comment><USER45> At this point, it's the best option for our huge energy needs. Like you said, a few decades down the road, solar power might be somewhat interesting. What do we do until then? Burn coal, which is far more polluting?

Next, solar and wind energy yield but peanuts in how much energy we actually need. A recent article suggests that, with impossible 100% efficient solar panels, we'd have to cover 1/6000th of the earth to meet our current energy demands. A few decades down the road this will probably be doubled because of our growing demands.

</comment></comment><comment><USER46> Even if reposted with fancy graphs, the data do not get better. Basically, they are from a nuclear lobby site.

The referenced data on the lobby site lists 0.04-0.23 deaths per TWh for the coal fuel chain and 0.01-0.65 for nuclear. I don't see that large a difference here between coal and nuclear.

The number of 160 deaths/TWh is made up from a very rough estimate of WHO that 1 mio. people die due to coal air pollution (without further reference). That's hardly a good source, IMHO.

Further, the effect of storing lethally radioactive material for very long time periods is completely neglected.

For me, this is a troll post and I bite.

<comment><USER47> > Basically, they are from a nuclear lobby site

Really? You may well know something I don't, but it doesn't seem that way to me: <http://www.reddit.com/domain/nextbigfuture.com/>

<comment><USER46> The info is based on such bogus data, I jumped to that claim. I currently can't check your reddit link, because reddit is down. Maybe it's just the article.</comment></comment></comment>


Ask HN: Google took down Chrome Extension without reason. What should I do now? - <AUTHOR> Hi all,
I run a bookmarking website (getkozmos.com) and it has a browser extension which is available on Github (https://github.com/kozmos/browser-extensions).
Google took down this extension without even a notice. I just got a message from a user and realized it was taken down, I can not see the reason. The only message I get from the store is "This item has been removed from the store because it did not comply with our policies or terms of service.".
I have a paid developer account and sent bunch of e-mails, also mentioned Google Chrome on Twitter.
No response so far. Noone opened the e-mails I sent (I can see if someone opens an I e-mail I sent, thanks to Superhuman).
I ran out of ideas. I can not imagine how a simple bookmarking extension doesn't comply their policy. All it does is creating a heart button in the browser, and providing a new tab interface to explore the bookmarks.
Ideas & recommendations welcome.
Azer <comment><USER2> Sorry I can not help, but I want to clarify, you can not see if someone "opens" an email. Simplifying a bit: mails are basically sent in plain text from mail server A to mail server B. What happens next highly depends on the scenario. If the recipient is an individual usually the client fetches the mail from the server and renders it as it pleases, hence tracking embedded in html is not necessarily rendered nor "read receipts" are sent back. In many other cases (e.g. corporate recipients, where different persons may look at it) the mail will be processed in some form and only plain text content extracted to be displayed in some ticket system.

<comment><AUTHOR> You're right. But still, we got no response for all e-mails we sent. Google Chrome's official Twitter account didn't even respond us once although we mentioned them so many times.

</comment></comment><comment><USER3> That sounds awful. Have you tried reaching out on their public Chrome forum ?</comment>


Perl is 25 years old today - <AUTHOR> http://perldoc.perl.org/perlhist.html <comment><USER2> I've found over the past decade or so that when I write a "perl" program I'm really writing about five lines of glue code around multiple CPAN packages. Well maybe more than 5 lines for control flow, some business-logic error handling, etc.

When I write in another language I spend a long time looking for a library like the ten I'd find in CPAN, sometimes I find one but often enough not, then a long time complaining about how if I used perl I'd have access to the perfect CPAN module and therefore already be done with the whole project, then basically reimplement the CPAN module in the smaller inferior language, then finally write glue logic to link stuff together.

I never fail to be amazed when I see pages and pages of an inadequate homemade xml parser written in an inferior language or maybe a blizzard of regex, and then hearing bragging about how in Perl the elegant alternative language code would closely resemble line noise. No, in Perl, those pages and pages of buggy code would instead closely resemble one line: "use XML::Simple;" Repeat a zillion times over.

My "perl" programs / systems actually shrink in length over time rather than expanding, which is unusual in smaller languages.

<comment><USER3> CPAN might be centralized, but Java libraries are far superior. This is not a pissing contest, but a fact. The java runtime makes everything else look amateurish and unprepared. Debugging, profiling, introspection and distribution, all built into the platform. Attach to any running process and analyze away. Perl is good when it works, but when it doesn't, it's cryptic stack traces and `exit -1`, nothing meaningful.

<comment><USER4> Not really true. Yesterday I was trying to debug resource-loading issues. In any normal programming language, you can just strace it and you'll see where the program is doing I/O and you can figure out where it's trying to load files from. But if everything is in a jar, you don't see any OS-level I/O happening when Java tries to load something, so you have to invent all-new tools just to figure things out. When you switch to Java you throw away 40 years of UNIX for a bunch of private methods implemented by summer interns at Sun 20 years ago. The third-party libraries are fine, but the core is not.

Also type erasure.

<comment><USER5> I agree but if we're comparing Java to Perl, type erasure is only slightly hacky compared to the whole 'bless' thing.

Funnily enough, they're both examples of the same problem, stitching new features onto a language that was not at all prepared for them.

</comment></comment></comment></comment><comment><USER6> I've got an interesting relationship with perl. My first exposure was back in the 80's when I was at Sun and perl was, to my taste, a shell scripting language with the complexity of APL and the readability of Forth. I hated it.

When I took the job at Blekko they said "We do most of our stuff in perl" and I was dubious about that.

However, now that I've been exposed to V5 for a couple of years and have probably written a few thousand lines of code in it, I find its easier to write a quick hack in than Python, and it certainly has a better 'command line' feel than Java. But it wasn't until I started coding up a quick CMS type gizmo for making HTML pages that I truly "got" the power of CPAN backing it up. There is a _lot_ of stuff there. Folks like me who gave up on the language in the V3/V4 days as "hopelessly hacky" should re-visit it.

<comment><USER7> The V3/V4 days ended in _1994_ , before Java 1.0 was released.

<http://perldoc.perl.org/perlhist.html>

<comment><USER6> I was first exposed to perl at Sun Microsystems in 1989, I started working on Java in 1992.

[http://stuff.mit.edu/afs/sipb/user/marc/hotjava/doc/people.h...](http://stuff.mit.edu/afs/sipb/user/marc/hotjava/doc/people.html) (top left corner)

</comment></comment></comment><comment><USER8> Before i switched to Python as my general purpose language, i used to be a bit of a Perl fanatic.

I've still to come across a language that lets you get your ideas down as quickly. It's full of fantastic time savers, e.g. the for(<>) construct and the format output functionality cover a bunch of common use cases in minimal keystrokes (let me pipe in some data, analyse it, then spit it out in a clean report).

It can hurt readability but for small one offs, it often doesn't matter.

<comment><USER9> My experience is almost exactly the opposite. Whenever I'm writing in Python I can't escape the feeling that the code is simply _fragile_ due to missing language features. Obviously this starts with all the regex initializations (often quite distant in source from where they are applied) which make regular expressions in python just a huge mess.

Perl's autovification allows me to build a data structure at parse time with code that is trivially verifiable. Python forces me to sprinkle the code with a thousand tests for whether or not the field is initialized yet, or write extra code to define things like defaultdict instances (with syntax that I always have to look up, and which in my experience most python programmers don't understand).

Not to mention that if I want to use an OO syntax for that data structure I have to write extra code defining a class for it (and inevitably be yelled at by the pythonista security branch for all the __whatnot__ methods I forgot to define).

Python's comprehension/generator syntax is nice, though, and doesn't have a clean analog in perl. One thing it does do well is chaining up "filter" operations on aggregate data structures in a clean way. And that has value and is worth emulating. But honestly most of the rest of the language is junk compared to perl or ruby.

<comment><USER10> I agree with you about the feeling of fragility, especially with defaultdicts.

As for regexes - while they are somewhat clumsy in python, they don't have to be defined distantly:

      m = re.match(r'(\d{4})', buf)
      if m:
        print "year: %s" % m.group(1)

The only thing that really bothers me about the above is the need to separate the assignment of m from the test.

Re comprehensions: seems to me they are just Python's version of Perl's map and grep.

grep:

      @good = grep { $_->{width} > 9 } @crates;
      good = [c for c in crates if c['width'] > 9]

map:

      @squares = map { $_ * $_ } @nums;
      squares = [i*i for i in nums]

Which is better? I think Ruby's way is the best, and Perl/Python are a wash here.

Now, on the autovivification note, I wonder if we can make a Python class that has the desired behaviors. Like:

      c = PerlishStruct()
      c['foo'][17]['bar'] = 'baz'

You don't really think it's junk, do you? Perl, Python and Ruby are extremely similar; I'd say Perl's more ergonomic, but messier; Python's cleaner, but sometimes awkward, and Ruby pretty much has the best of both worlds.

<comment><USER11> You probably shouldn't do this in an inner loop: :-)

      m = re.match(r'(\d{4})', buf)

'map' is more general than just the single, convoluted statement of list comprehensions, which really seems as a kludge from unwillingness to accept multi-line lambdas. So something new was invented that had to be learned; then it was argued it is a boon. (Like references in Perl. :-) )

(There is some defaultdict functionality for autovivification in Python iirc.)

Yeah, they are all similar. I don't know enough Ruby to have an opinion.

</comment></comment></comment></comment><comment><USER12> I'll raise the glass: here's to Perl, for being the first language I could actually get shit done in.

Unmaintainable? Who cared. Got shit done. Too many ways to do things? Who cared. Got shit done.

I have this totally false feeling that BACK THEN* we wrote IRC bots and we were happy. And `perl -e '"A"x800'` was the destroyer of worlds.

* - shit, I just realized I'm young.

<comment><USER13> I like that Perl tends to do what you wanted it to do, rather than what you told it to do. Bugs in other languages are often because of vice-versa.

</comment></comment><comment><USER14> Perl is 25. Python is 21. Lua is 19. Ruby is 17.

Interesting how I consider Perl an 'old' language, and the others new languages. I guess it says more about how revolutionary Perl was at the time and how quickly it became widespread. The only other language I know of that went from 0 to everywhere in under 5 years was Javascript.

<comment><USER15> Common Lisp is 28, which a year younger than C++ and not much older than Perl. So not a dinosaur language as some people think. <g>

<comment><USER16> Lisp was invented 54 years ago. The Common Lisp standard is the capstone on an unusually long and fractured history of development. Fortunately many of those good ideas have trickled down over the decades, making mainstream languages steadily less terrible, and competing proprietary implementations are no longer commonplace.

<comment><USER17> > Lisp was invented 54 years ago. The Common Lisp standard is the capstone on > an unusually long and fractured history of development.

Hm. If we do this, then C++ is merely one 'capstone' on the history of Algol development, which is about as old as Lisp is.

</comment></comment></comment></comment><comment><AUTHOR> Here is another article covering a good deal of detail about Perl in its first 25 years, Its a great read: [http://news.perlfoundation.org/2012/12/the-first- twenty-five...](http://news.perlfoundation.org/2012/12/the-first-twenty-five- years.html)

</comment><comment><USER18> Work stuff is mostly Ruby, Python and PHP. Entertainment is Clojure (mmmmm.... Lispy goodness) and Haskell ATM.

But for my own stuff I still reach for Perl. Best testing infrastructure on the planet and that, in combination with CPAN, lets me get shit done.

<comment><USER19> I interviewed you once ... approximately forever ago ... and you told me at the time you were just switching to using Ruby for fun stuff, while using Perl for work. I'm glad you switched back, and appreciate your excellent CPAN modules!

<comment><USER18> I have completely forgotten the interview I'm afraid - but I'm glad you're glad ;)

</comment></comment></comment><comment><USER20> Here's Perl 1.0, published by Larry on comp.unix.sources 25 years ago ("Revision 1.0 87/12/18 13:07:40 root").

[https://groups.google.com/group/comp.sources.unix/browse_frm...](https://groups.google.com/group/comp.sources.unix/browse_frm/month/1988-02)

                           Perl Kit, Version 1.0

                       Copyright (c) 1987, Larry Wall

          You may copy the perl kit in whole or in part as long
                as you don't try to make money off it,
                     or pretend that you wrote it.

<comment><USER21> Slightly self-promotion, but you can get a variety of old perl sources at <http://www.etla.org/retroperl/> (collected by someone non-me, I can't remember who though)

I had thought someone had done a perl 1 release that built on modern systems, but on a quick hunt I can't find it.

<comment><USER22> The perl source repository quite many historic releases also, and the first few commit messages also contain the accompanying release notes.

See for example [https://github.com/mirrors/perl/commit/8d063cd8450e59ea1c611...](https://github.com/mirrors/perl/commit/8d063cd8450e59ea1c611a2f4f5a21059a2804f1) for the perl 1.0 annoucement (click on the [...] link to get the full commit message).

<comment><USER21> ooh, cool, I didn't know that was there.

My more active interest in perl was pre-git :)

</comment></comment></comment></comment><comment><USER23> The stats in the link are interesting. I recently discovered the Code::Statistics module (<https://metacpan.org/module/Code::Statistics>). It tells you the cyclomatic complexity of your code which wikipedia tells me is basically the number of possible paths through your code.

It might be fun to see that run against the Perl core.

I also like looking at the number of lines of code. If your features go up while complexity and lines of code go down -- that could be a good sign.

</comment><comment><USER24> Happy Birthday, Perl :). At Crowdtilt, we are proud to have the majority of our stack Perl based. w00t w00t CPAN :)

<comment><USER25> Came here looking for someone else wishing Perl many happy returns as it reaches this august landmark.

I have been working as a programmer for 25 years and started using Perl in 1993 or so. I cannot express what it felt like to have this incredibly powerful tool that seemed to integrate all of the sed, awk, shell, and C code that I had for research. Using Perl absolutely felt like magic, particularly for analyzing text.

I love Python, Ruby, and Lua too, but Perl will always be the tool that quickly gets things up and running.

</comment></comment><comment><USER26> I believe most mainstream languages used for web development are quite old now. And today it is matter of personal taste to choose one over another one unless you are constrained by coding standards.

To me Perl is awesome :) Too bad I do PHP for a living, but I still enjoy it when doing something for myself. Like last time I learned about web framework Mojolicious ( <http://mojocasts.com/> ) and built <http://gotldr.com> and <http://hntldr.com> leveraging Mojolicious and Redis - <https://github.com/hippich/perl-tldrer> . It took me few evenings, but I really enjoyed tinkering it.

</comment><comment><USER27> Twenty-five years already? Now it can retire with full benefits.

</comment><comment><USER28> I haven't written a single line of Perl for over a year now and can't remember much of the language - and I am sure I would not even be able to understand my own code anymore!

Perl is a very handy and powerful scripting language but it should not be considered as a durable solution. Whatever is quickly hacked using Perl should be probably rewritten in a much more structure language, especially if you plan on maintaining this code.

<comment><USER29> Of course one can also write perl with care and attention. Perl::Critic, the Moose family, and appropriate use of the CPAN really helps with that discipline.

</comment></comment><comment><USER30> Birthday cake! <https://twitter.com/TimToady/status/281119953741029376>

</comment><comment><USER31> Unfortunately it looks like the interest in Perl may be fading a little according to Google trends: [http://www.google.com/trends/explore#q=perl%2C%20python%2C%2...](http://www.google.com/trends/explore#q=perl%2C%20python%2C%20&cmpt=q) (Perl vs Python for comparison)

<comment><USER32> Please do yourself a favor and mouse over the letters indicating news headlines. :)

</comment></comment><comment><USER33> I like perl "expression": perlguts, bless, sv_2mortal, etc i feel we are listening the same song :)

</comment><comment><USER7> As always, XKCD sums up the situation: <http://xkcd.com/224/>

</comment><comment><USER34> Do people really still use Perl? It seems to have yielded greatly to other languages in the past few years.

<comment><USER32> Absolutely: <http://stats.cpantesters.org/trends.html#stats6>

</comment></comment><comment><USER35> And Perl 6 is 24

<comment><USER30> Considering perl5 is only 18 years old then somethings gone very awry there :)

Perl6 is looking quite _fresh_ considering how old you think it is. I just submitted an article I'd seen to HN which shows how a formula like...

      4.7kΩ ± 5%

... can be parsed inline with Perl6 code.

<http://news.ycombinator.com/item?id=4939204>

<comment><USER35> I was just joking :)

It's interesting to me how often people cite "Unicode in code" as some sort of amazing thing. I once posted on S.O. about the idea that maybe we should have a programming language where the vast array of options in Unicode were exploited to make things like Regular Expressions more readable (avoiding the backslash plague alone would be worth it).

I got smacked down by people complaining that they didn't know how to type anything but ASCII.

Sigh.

<comment><USER30> _Jokes_ tend to get downvoted on HN and there's been a few (to many) _jokes_ in this HN post :( Your's the only one I didn't downvote because decided to leave a comment instead.

re: Unicode - Perl6 does already use unicode characters for some of its operators. Take the Hyperoperator »« (<http://perlcabal.org/syn/S03.html#Hyper_operators>):

      my @a = 1..5;
      my @b = 6..10;
      my @c = @a »*« @b;   # =>  6, 14, 24, 36, 50

And there are _> >_ & _< <_ synonyms for those who find using unicode chars too odd:

      @c>>++;   # =>  7, 15, 25, 37, 5

<comment><USER35> Italicizing "jokes" is a very serious accusation.

</comment></comment></comment></comment></comment><comment><USER36> This one is a real perl see --

                               |
                              \|/

[http://stackoverflow.com/questions/7617852/whats-the- differe...](http://stackoverflow.com/questions/7617852/whats-the-difference- between-carp-croak-cluck-confess-and-verbose-options)

<comment><USER37> I vomited a little when I read that :)

<comment><USER38> I was going to downvote your comment, but then I clicked through and read the linked question and commentary.

<comment><USER39> I don't get what the issue is, I don't even know Perl and it seems pretty straightforward to me: Carp is a library with a set of mnemonic assertion functions for libraries to signal usage errors committed by their callers.

Do people just prefer one function with a bunch of fiddly little enums or something?

<comment><USER37> In my case I prefer sensible pragmatic names with some sort of hierarchy rather than random words from the dictionary.

</comment></comment></comment></comment></comment><comment><USER40> should have died 20 years ago its an awful language in my opinion

</comment><comment><USER41> What can I say, it's time to die.

<comment><USER11> A karma 3 account.

Where are the Perl-hating trolls coming from on HN?

(I thought Guido said that it was time to stop trolling, so it isn't Python people now?)

<comment><USER27> Hate is an emotional response that humans have ... how can you tell if the comment was trolling or simply a visceral response?

I don't hate Perl (I first learned CGI programming with it), but I do think there are better ways to write maintainable, enterprise scale software. There are two main problems with Perl (as I see it): 1) The language is so permissive that it allows newbs to write bad code but still obtain results. Habits, both good and bad are learned! 2) Perl experts seem to delight in writing code that's "tricky" (for lack of a better word). It's like a contest to see who can wring the most out of one 80-character line of code and it leads to mid-to-low functioning Perl programmers being confused.

<comment><USER11> >> The language is so permissive that it allows newbs to write bad code but still obtain results

I can't see any relevance for a _professional_ choice if newbies can shoot bigger holes in their foot with a certain tool.

That is a natural result of a powerful tool.

>> Perl experts seem to delight

Anecdotal. Ten years old description of half humorous use (and exercises). Also very different from best practices even then -- and especially different from how many/most work today.

Let me also note: If Perl wasn't better in many ways, you trolls would make serious arguments instead of " _experts seem to delight_ "... [Or as you wrote above " _Twenty-five years already? Now it can retire with full benefits._ "]

But I'll bite a little. Perl has the best OO system of all the scripting languages (Moose). The CPAN is the gold standard for scripting languages (and probably everything else). The testing culture is afaik second to none. The same goes for Unicode support. And so on.

<comment><USER42> I respect Perl and people who use it, but this is a telling cultural artifact: <http://www.ozonehouse.com/mark/periodic/>

I am not posting this to bag on Perl, but just to show its fingerprint. If you find that periodic table to be funny or cool then you are a lot more likely to be happy with Perl than if it makes you shudder.

<comment><USER11> You claim to _really_ not be aware that table is for a quite different language -- Perl 6?

That point has been made many, many times.

Edit: To the _cultural_ question, there might be a point. I might add that I don't know Perl 6, but it seems like an insane amount of cool/fun toys (macro language like lisp with an Algol-like syntax?! If they can pull that off it is incredible.) That might say something about me and Perl people. But people I admire use both vim and Windows, so I'm not certain.

<comment><USER42> I also think Perl 6 has some really cool and innovative ideas. Far from using it to smear Perl, I think it is more interesting than previous versions.

But you are in denial if you think that this chart isn't a reasonably representative cultural artifact of the Perl community and the Perl aesthetic. Perl 5 is not exactly poor in operators, and it is the same core community which produced both.

I don't think that Perl is bad. I am saying that Perl is very strongly what it is. And while some people won't like that aesthetic, I don't see why anyone should apologize for it.

<comment><USER43> Is there really such a great difference between operators vs. class/method/function names? E.g., Math.pow() vs. __?

<comment><USER44> There's a huge difference in searchability for one.

<comment><USER43> Maybe, though personally, "perl operators" has never failed me in Google.

<comment><USER11>
       $ perldoc perlop</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


Deep Red: The Beginning of the End of a Familiar Open Source Business Model? - <AUTHOR> https://blog.upbound.io/from-red-and-blue-has-the-as-a-service-model-won/ <comment><USER2> I do wonder how the announcement went down. Can you imagine, you work for Red Hat developing open-source, then one day find out you've been sold to IBM?? funny when it doesn't haooen to you I guess, hahaha.

<comment><USER3> In the sale of a corporate entity to another corporate entity there are always lots of sets of competing (false?) binary opposites: the vested, and un- vested. the contracted, and the uncontracted. The knowledge workers and the cleaners.

You should not assume there is a single binary choice feeling here. I could imagine a contract cleaner in Red Hat facilities checking out how well IBM pay cleaners, and deciding they prefer IBM, or go to another job. A vested knowledge worker, who is looking at both realizing their vesting state _and_ acquiring a huge tax bill might have more than one view.

A new hire, who dreams of working in IBM Zurich might rub their hands with glee.

"it depends"</comment></comment>


Show HN: www.WikipediaTop.com - what's hot - <AUTHOR>

http://www.WikipediaTop.com
I am curious about extracting info from data.
So this is a small project to visualize what's buzzing on Wikipedia.
This is an early iteration - I will try to improve it in the future.
Feedback is welcome! <comment><AUTHOR> Here is the link: <http://www.WikipediaTop.com></comment>


Why and How to Get the Most Out of Twitter - <AUTHOR> https://www.andreykurenkov.com/writing/life/twitter-tips/ <comment><USER3> Right now trying to grow my followers number. Though it looks like people get used to retweet & like quite trivial posts like, "how to live properly: - <USER2> well, - sleep 8 hours ..."</comment>