Agda Tutorial - <AUTHOR> http://people.inf.elte.hu/divip/AgdaTutorial/Index.html#

<comment><AUTHOR> I haven't had the chance to watch the two videos yet, but at BFPG (2015-03), Matthew Brecknell did an " _Introduction to Agda_ " talk that might also be interesting to some.

[https://www.youtube.com/watch?v=QyUVONbwHYE](https://www.youtube.com/watch?v=QyUVONbwHYE)

[https://www.youtube.com/watch?v=7iAkFh9xOIc](https://www.youtube.com/watch?v=7iAkFh9xOIc)

</comment><comment><USER2> If you're interested in learning Agda, you might want to check out Conor McBride's courses, given at the University of Cambridge:

"Introduction to dependently typed programming using Agda", 2011:

[http://www.cl.cam.ac.uk/~ok259/agda- course/](http://www.cl.cam.ac.uk/~ok259/agda-course/)

Course materials:

[https://github.com/mietek/agda-introduction](https://github.com/mietek/agda- introduction)

"Dependently typed metaprogramming (in Agda)", 2013:

[http://www.cl.cam.ac.uk/~ok259/agda- course-13/](http://www.cl.cam.ac.uk/~ok259/agda-course-13/)

Course materials:

[https://github.com/pigworker/MetaprogAgda](https://github.com/pigworker/MetaprogAgda)

</comment><comment><USER3> Agda, Coq etc is something I really want to learn someday. I'm already pretty proud that I finally can write some haskell, but this stuff is next level. I might give Idris a go first though, as it seems very similar to haskell in syntax.

<comment><USER4> With Agda, I found that understanding the dependent type system, the basics of proofs, and why the Curry-Howard equivalence holds, was all pretty easy. It makes sense—it's, uh, logical. The Emacs mode for it is like a gamification of deductive reasoning; very fun.

Then grokking the module system and the basic proof tools in the standard library, that was a little hurdle. I spent a weekend writing up some basic definitions from group theory, and it was a lot like learning some other language, confusing at times and requiring trial and error. Very worth the effort!

I think the basic insight behind the Curry-Howard thing can be indicated very simply. A function type "A -> B" says that given some arbitrary A, you can come up with an element of B. In other words, "forall A there exists a B".

For this to actually hold, the language needs to prevent cheating, i.e., prevent terms having type X that don't actually evaluate to an X — like Haskell's error function which has type "forall x. String -> x", or infinite recursive definitions like "x = x".

Dependent typing is simple too. It just means that the types are made up of first-class values no different from expression values. You can't reasonably do this in Haskell because Haskell's expression values aren't guaranteed to terminate, and a type checker should terminate.

I'd love to use such a language for modelling the domain logic of programs, but I never got further than experimentation.

<comment><USER5> The function type A -> B corresponds to A => B in logic. This is a subtle but important difference between logic and type theory. In logic a statement is true or false, but that's it. In type theory a statement (= type) has evidence (= values of that type). The type A -> B can be interpreted as turning evidence for A into evidence for B.

The logical statements "for all x:A it's the case that B(x) holds" and "there exists a x:A such that B(x) holds" correspond to dependent function types `(x:A) -> B x` and dependent pair types `(x:A, B x)`, respectively. In intuitive terms "if you give me an x:A, then I give you evidence of B(x)", and "I give you an x:A, along with evidence of B(x)".</comment></comment></comment>


Show HN: Startup Tool Directory - <AUTHOR> https://www.stacklist.com/tools/ <comment><AUTHOR> you can find over 1500+ tools used by startups here. Before this page was a list of all the tools but we've added pagination and filtering/sorting options to give better UX and help users find tools easier. Clicking on a tool will take you to a page where you can see startups that use it, and reviews from the founders of those startups. would love any feedback!</comment>


Ask HN: Why is hiring still so difficult? - <AUTHOR> There are countless of recruiting startups. Why is hiring still not "solved"? I hear recruiters complaining about this daily. <comment><USER2> Many recruiters spend that time complaining _instead_ of learning anything about the roles they're trying to fill.</comment>


Gchat concept app for iOS - <AUTHOR> http://www.behance.net/gallery/Gchat-concept-iOS-app/7256351

<comment><USER2> The contacts list menu on the side looks great, I love how so many apps are adopting a nice side menu instead of permanent tabs that get in the way.

How long did you spend on this?

</comment><comment><USER3> this app would be AWESOME</comment>


Snapgoods: Like Zipcar for Gadgets - <AUTHOR> http://www.crunchgear.com/2010/07/26/snapgoods-like-zipcar-for-gadgets/

<comment><USER2> I like these lending sites, but as a newly minted lawyer, I keep hearing "What If" sirens in the back of my head. I understand you only lend to trusted people, but what if trusted person returns the good in not-so-good-but-not- terrible shape. The lender keeps the security deposit, the borrower thinks he shouldn't have, do we then go to litigation? Do we trust the good will of people or some kind of community-based reputation? I think this could certainly get a little dicey if it ended up being popular, especially in edge cases like the one above.</comment>


Mind the Gap (2004) - <AUTHOR> http://paulgraham.com/gap.html

<comment><USER2> I'm not sure I buy this argument.

First, while people may be increasingly equal in material goods I think a fair argument could be made that they are increasingly unequal in political rights. The Koch brothers have much more political power than the average American,for example, and most of that is down to money equalling speech.

Second, there's the question of whether skill is actually rewarded perfectly, or whether there are social factors at work, making someone's race and class an arbitrary handicap.

Third, it's entirely possible that people contribute far more than those at the top think. Sure, you might not swap your superstar basketball player for a guy off the street, but how far would you get without a good team doctor, or accountant, or the police officer who stopped them being mugged, or the midwife who kept them alive in childbirth? I think the argument for only some people being 'wealth creators' ignores the fact we all rely on other people most of the time.

Fourth, there seems to be a large excluded middle. For example, the argument that:

> If you suppress variations in income, whether by stealing private fortunes, > as feudal rulers used to do, or by taxing them away, as some modern > governments have done, the result always seems to be the same. Society as a > whole ends up poorer.

... suggests a choice between two extremes.

What's wrong with a system which allows some variation but also keeps it from getting extreme?

<comment><USER3> Absolutely. You need to reward people for contributing, and you need to avoid handing masses amounts of power over society to a tiny part of it.

</comment></comment><comment><USER4> The fundamental statement of this article is wrong. General use of the term "wealthy" in our society includes investment bankers. By the definition in this article, they should only be considered "rich", because they increase the amount of money they have, but other people provide the wealth.

The definition therefore doesn't match common vernacular, leading to a number of incorrect conclusions. This is merely a game of alternate vocabulary, not analysis of reality.</comment>


AAPL hits $1T market cap according to Apple's own Stocks app, but it is wrong - <AUTHOR> https://9to5mac.com/2018/08/02/apple-becomes-first-company-to-hit-1-trillion-market-cap-according-to-apples-own-stocks-app/ <comment><USER2> The title has since been changed and an update posted at the top of the article:

> Update: 11:49 AAPL has now passed the $1T mark and is the world's first > trillion dollar company.

</comment><comment><USER3> It doesn't take count of discounted/light taxation (especially in Europe) that many small businesses don't have</comment>


Shazam Has 50 Million Users and Secures Investment From KPCB - <AUTHOR> http://www.billboard.biz/bbbiz/content_display/industry/e3ibadf593c28401ee842612eb017b4bf6a

<comment><USER2> i used to work for the company that now owns the music recognition algorithm that shazam is using. it's staggering how much hardware it takes to make this stuff work. they have a database of millions of songs, all of which must be kept in ram at all times, to make recognitions fast. it requires hundreds of linux servers.

despite my preference for stuff i've actually worked on, i think the midomi app works just as well or better. but they were late to the party, so they're having trouble getting the eyeballs.

</comment><comment><USER3> Shazam is _the_ song identification app on the iPhone. The real question is whether they're actually making money off of their iTunes referrals; KPCB seems to think/know so.

</comment><comment><USER4> I wonder how they are calculating users... The iPhone app has 10m downloads, hard to believe that the other platforms (BlackBerry, Android, etc) account for more than 80% of their users.

</comment><comment><AUTHOR> Goes to show that: urgent need + simple solution = home run.

<comment><USER5> You seriously ought to reconsider your definition of a home run.

<comment><AUTHOR> I think if you build a product that 50 million people love, or that 10 million people have downloaded, that would be considered to be a home run. If that isn't, what is?

<comment><USER5> 50 million downloads is a great thing and a big deal. But it is not a homerun. Home run almost exclusively refers to a liquidity event: either selling for hundreds of millions or billions or going public.

<comment><AUTHOR> I guess everyone has different definitions. 50 million users is a pretty tough benchmark to get to, especially in a little over a year. Hell, I'd be happy if there were 1000 happy customers for my apps. But damn if your bar is set on IPO, more power to you.</comment></comment></comment></comment></comment>


Nudging out support for a carbon tax - <AUTHOR> https://www.nature.com/articles/s41558-019-0474-0 <comment><USER3> This is happening in Ontario right now as we speak.

The Ontario government is fighting against the federal revenue-neutral carbon tax and has instituted a small grab-bag of subsidies for businesses doing green refits.

So in essence, they're taking a neutral system that put money to taxpayers and turned it into a subsidy on corporations that pollute, and claiming it as a populist victory. And the public ate it up.

I've heard nonsense like "I recycle and don't litter, why should I have to pay a carbon tax" as if those things are related.

<comment><USER4> It should also be noted that the federal carbon tax is a tax-and-rebate scheme. Ie you get taxed on the carbon and the revenues get refunded to the consumers. If you make a lower-carbon choice, you keep your money. If you don't, nothing really changed. It's also slightly progressive, since lower- income folks will actually come out ahead by a bit without making any changes.

Warning: strong political opinions below.

What we're seeing is really a replay of the ACA reaction in the US. Obamacare was a rejigged Romneycare, which was a rejigged Heritage Foundation plan which was a reaction to the Clinton's healthcare plans. It was a conservative, market-friendly approach to solving an issue... until it was actually implemented. Then we found out it was just a talking point meant that was never meant to be acted upon, a mere cover that allowed conservatives to pretend they were interested solving an issue.

Likewise, the tax-and-rebate scheme is basically most conservative and market- friendly approach to tackling climate change that actually produces results. But now that it's actually been implemented, the Ford/Kenney/potential-Scheer governments are reacting by repealing it and replacing it with nothing that produces results. Because they don't have the guts to say simply "No, we don't believe in this and we're not going to do anything about it"

<comment><USER5> Lets say it cost consumers $100.

After Carbon tax, company gets $20 tax. Price becomes $120. Government says to consumer, here's $20. Consumer and company see no difference. Government cost goes up to maintain the scheme.

This is why people say the carbon tax/price must go towards non carbon ressearch/products.

<comment><USER6> Let's further say that there exists another company that can produce the same widget with fewer emissions, but it costs $110 base price + $0 carbon tax to do so. Now the green company actually has a viable product, and consumers are incentivized to switch to it.

<comment><USER5> Consumers still see $100 net pre and post tax. That's why I think the rebates are flawed.

</comment></comment></comment></comment></comment><comment><USER7> In researching what we can do about climate change, the most convincing proposed policy solution I've seen comes from the Citizen's Climate Lobby -- a Carbon Fee and Dividend ([https://citizensclimatelobby.org/basics-carbon-fee- dividend/](https://citizensclimatelobby.org/basics-carbon-fee-dividend/)), which I learned about while reading "Being the Change" by Dr. Peter Kalmus.

Basically, it's a plan for a carbon tax along with a rebate program (similar to UBI in my opinion) so that the least well off financially don't get crushed by things like higher gas prices.

<comment><USER3> That's actually what was implemented in Canada last month on all provinces that didn't run their own carbon pricing system.

You'd think everybody could get behind it, right? I got $300 on my tax rebate as an advance for this year's carbon pricing.

Of course the conservatives hate it, because their carbon plan is "no."

And they're on track to win in November.

<comment><USER8> We shall see. A lot can change between now and then. The SNC affair will fade over the summer and the truth is the economy is doing very well - <USER2> typically drives election results.

<comment><USER3> I wish I shared your optimism. I keep worrying we're going to see a repeat of Ontario's provincial election.

</comment></comment></comment></comment><comment><USER9> We need to just introduce that damn tax already. We should have introduced it thirty years ago after the Rio summit! The longer we wait the harder the transition will become.

<comment><USER10> It's currently before Congress

[https://energyinnovationact.org/](https://energyinnovationact.org/)

<comment><USER11> Nothing moves in Congress right now because Mitch McConnell is only interested in confirming judges as fast as possible. And he has been explicit in being non-cooperative with Democrats.

</comment></comment></comment><comment><USER12> An under-represented argument for a carbon tax is the fact that it would encourage companies to innovate, both with respect to efficiency as well as using renewable energy.

I predict that industries in countries that adopt a carbon tax earlier will end up with a competitive advantage.

<comment><USER13> I'll go further with the example of the U.S. car industry in the 60s, when the evidence was clear that consumers preferred safe, reliable, affordable, efficient cars -- from increasing sales for Volkswagen and Toyota, and most of all from the success of _Unsafe at Any Speed_.

I doubt anyone then would have predicted that two of the U.S. big three would declare bankruptcy and that Toyota, then manufacturer of podunk little cars, would become the #1 manufacturer, but it happened.

Had U.S. regulations met consumer demand, U.S. manufacturers may have innovated what consumers wanted instead of more chrome, tail fins, size, etc. Regulation came eventually, but too late for the industry to avoid bankruptcies, unemployment, and so on.

In fact, regulation didn't stifle innovation but directed it. Engineers can innovate around safety and efficiency as much as on speed and tail fins. I'd rather have 100,000 mile warranties and electric cars than more chrome, which U.S. market forces created.

Today, regarding the environment, the governments that regulate to reflect citizen demand for clean air, land, and water will create markets and companies that beat ones that don't. I hope current U.S. policy doesn't bankrupt more future U.S. markets and companies.

</comment></comment><comment><USER14> Full text pdf: [https://www.researchgate.net/journal/1758-678X_Nature_Climat...](https://www.researchgate.net/journal/1758-678X_Nature_Climate_Change/publication/333068802_Nudging_out_support_for_a_carbon_tax/links/5cda4b91299bf14d95950a77/Nudging- out-support-for-a-carbon-tax.pdf)

</comment><comment><USER15> The latest IPCC report says we have just 11 years to halve global emissions or we'll be seeing massive destruction to civilization. This is what is spawning organizations like Extinction Rebellion, which forced the UK government to declare a climate emergency. A tax now seems like too weak a measure. Greta Thunberg and Extinction Rebellion and others are talking about 15% reductions annually in industrialized countries. Any other proposal accepts doom or millions of unnecessary deaths as options.

</comment><comment><USER16> So market driven. So incentive-based. So flat. So American.

America loves to do things via tax code, which is why the US tax code is famously so complicated, but that time is gone. The answer isn't a new tax to nudge the market. The answer is not an incentive to _please_ stop polluting. We don't need 10% reductions here and there. We need massive reductions everywhere, preferably with active capture that pushes carbon emissions into _negative_ territory. We cannot afford to fund green energy by taxing non- green energy. Coal cannot fund solar. Coal has to stop. We need rules to say that burning coal is now illegal. We need rules that mandate solar+wind as a fixed percentage of energy generation. We need massive rewrites to the rules that limit the deployment of new nuclear technologies. The opportunity for politically-friendly market-based (ie American) approaches has passed. It is time for governments to pass absolute rules forbidding some behaviors and mandating others. If that offends political sensibilities, those political sensibilities need to be set aside.

(1) Burning more than 100kg of coal per year is illegal.

(2) All new houses must include 10m2 of solar panels per resident.

(3) Windmills are, by law, not "an eyesore". No more complaining about them spoiling your retirement view.

(4) Those who cannot articulate the difference between a millisievert and a microsievert, between fission and fusion, are not allowed anywhere near the planning meeting for any new power plant.

<comment><USER17> Incentives work really really well. Almost nothing else does over the long term.

For a concrete alternative with incentives: [https://citizensclimatelobby.org/basics-carbon-fee- dividend/](https://citizensclimatelobby.org/basics-carbon-fee-dividend/)

A massive $600 billion dollar per year incentive based nudge.

<comment><USER16> [https://en.wikipedia.org/wiki/Montreal_Protocol](https://en.wikipedia.org/wiki/Montreal_Protocol) : absolute ban on CFCs worked.

[https://en.wikipedia.org/wiki/Tetraethyllead](https://en.wikipedia.org/wiki/Tetraethyllead) : EPA mandated reductions of lead in gasoline worked.

Not to mention the thousands of little things (drunk driving, slavery, universal suffrage, speed limits etc) that were overturned relatively successfully without any market-based approaches. There is a right-wing philosophy that all government actions are inherently inefficient, but the reality is that laws work. It is possible to ban a behavior on day one and see it substantially reduced on day two.

<comment><USER18> China has continued to leak CFCs despite the ban.

<comment><USER19> CFCs in the atmosphere are still dropping. (The news was that the rate at which CFCs disappear has slowed down a bit, and some are pointing at China for that.) I'd say the policy was pretty effective.

<comment><USER18> I don't think China deserves the benefit of the doubt on this topic.

"From the Korean and Japanese data, we used our models to show that emissions of CFC-11 from north eastern China had increased by around 7,000 tons per year after 2013, particularly in or around the provinces of Shandong and Hebei," said Luke Western, a University of Bristol atmospheric modeler. "We didn't find evidence of increasing emissions from Japan, the Korean peninsula or any other country to which our networks are sensitive."

[https://www.cnn.com/2019/05/22/health/china-cfc-pollution- en...](https://www.cnn.com/2019/05/22/health/china-cfc-pollution-environment- intl-scn/index.html)

<comment><USER19> OK, the emissions were indeed confirmed to be coming from China. Fortunately they are tracking down the CFC producers now and shutting them down: [https://nationalpost.com/news/world/china-makes-arrests- shut...](https://nationalpost.com/news/world/china-makes-arrests-shuts-down- rogue-chemical-factories-that-spewed-banned-ozone-depleting- gas?fbclid=IwAR2D_XkH2BtI20r1AeessWBVp8uMXyIWpe5L4wQ1FZAPaWUreQjuwoszVU4)

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> I don't think you'd see as much resistance to such a tax if it was dollar for dollar paired with a reduction in other taxes. This has two benefits:

1) In the absence of this pairing it just looks like a government-growing cash grab to a segment of the population.

2) People who aren't even convinced of the dangers of AGW can still support it.

<comment> shaki-dora I wish I had your optimism. I'm almost certain that even a revenue-neutral bill would be presented as a tax increase in the right-wing media.

And, of course, even something that is revenue-neutral overall will have some winners and losers: SUV owners will pay more than those commuting with public transport. Poorly isolated single-family homes in the south relying on air conditioning through the summer will be more expensive compared to flats in northern brick houses, etc.

<comment><USER21> > SUV owners will pay more than those commuting with public transport. Poorly > [insulated] single-family homes in the south relying on air conditioning > through the summer will be more expensive compared to flats in northern > brick houses, etc.

Those all sound like _excellent outcomes_ in terms of linking behavior to carbon emissions via a price-signaling mechanism.

Logically, it's impossible to simultaneously incentivize people to emit less _and_ not have the current high emitters feel some incentive to change.

(Edit: removed one extraneous negation in the last sentence.)

</comment></comment></comment><comment><USER22> I personally wonder if taxing carbon producing machines makes more sense than taxing fuel? The taxes could directly subsidize cleaner alternatives.

Then, once a lot of carbon producing machines are out of use, introduce a carbon tax to help push the remaining ones out?

</comment><comment><USER23> Instead of calling it a tax, let's just say we're going to stop subsidizing carbon.

</comment><comment><USER24> This won't be popular with the HN crowd, but taxing activities that we want to reduce/minimize doesn't work. Cigarette taxes didn't work in any meaningful way (see [https://www.nber.org/papers/w18326.pdf](https://www.nber.org/papers/w18326.pdf))

<comment><USER12> I don't think the comparison to cigarette taxes is completely fair. Cigarettes are relatively inelastic w.r.t. price as they are addictive, and have no real competing product.

Electricity and power generated from carbon emitting sources on the other hand have a much more elastic demand curve. E.g. if your energy bill is cheaper with renewables, no one would choose to go with fossil fuels. Likewise with electric vehicles. If the cost of tanking up an EV is significantly lower than an internal combustion vehicle, people will switch for purely economic reasons.

You can look at the lack of a carbon tax as an incentive on fossil fuels which socializes the externalities.

</comment></comment><comment><USER25> I think this sums it all up "but is controversial because it imposes costs on consumers."

A carbon tax is a way for all of us (people) to deal with the problem, while the corporations that created and caused it get a 'get out of jail free' card.

<comment><USER9> Corporations don't burn coal for fun, they satisfy demand created by people like you and me while trying to maximize profits. Without a carbon tax, corporations that manage to successfully externalize that cost have a huge competitive advantage.

<comment><USER26> Companies don't pay taxes for fun, either. What I think that comment is referring to is the fact that corporations have a history of being really good at weaseling their way out of paying taxes, and the bigger companies are the best at it.

A carbon tax, in particular, looks like it would be very easy for a multinational to escape. It's reason #{xyz} to move your facility across the border and out of American jurisdiction.

If we can't get them to pay taxes already, won't a carbon tax simply be yet another tax which is disproportionately paid by small businesses and individuals, and not the actual biggest polluters, while driving more manufacturing jobs overseas to countries which don't have such laws?

<comment><USER27> I guess the solution here is to have customs duties based on emissions taxes paid in the originating country. This is not only needed to prevent corporations from moving their business elsewhere, but also to compete with existing/new corporations in foreign countries.

<comment><USER21> You can't base duties just on emissions taxes paid. (Setting aside practical record-keeping concerns,) If factory A pays no emissions taxes paid because they're based in a country without carbon taxes and factory B pays no emissions taxes because they're in a country with no carbon taxes _but also_ are using carbon-free energy sources and factory C is located in a country with carbon taxes and pays those taxes, should we charge B the same as A in duties? Should A pay more than C by the exact amount of the carbon taxes? If C implements an energy efficiency program to cut its consumption in half, should A now pay less? How could B "prove it"? How do we control such that A can't represent itself as B?

At some point, these other countries are sovereign entities, and it's going to be difficult to dig into the on-the-ground facts at each factory and step along the supply chain to determine emissions.

<comment><USER27> We can measure CO2 emissions from space:

[https://climate.nasa.gov/climate_resources/99/graphic- measur...](https://climate.nasa.gov/climate_resources/99/graphic-measuring- carbon-dioxide-from-space/)

If company X in country Y wants to trade with the US, they could require that country Y provides full transparency in carbon emissions, where the measurements from space could be used as a checksum.

<comment><USER21> Neat tech. (For those curious, it seems like we are capable to measure CO2 increase or decrease to an uncertainty of approximately 0.3% [of CO2, meaning ~1ppm overall]. That's impressive.)

Even if the last "embargo uncooperative countries" strategy were possible, I think you'd find that all of their domestic production would be carbon- intensive and their exports would all be "carbon neutral".

<comment><USER27> Well, we could require that countries (trade partners) pay tax on their emissions as opposed to companies. How these countries tax their companies internally could be an internal affair entirely. And this also solves the bookkeeping at the border.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> Grand projects like TVA and Tesla Inc are what will solve global warming.

Carbon tax is just money. More money doesn't solve global warming. In fact I would say money is the reason we have global warming in the first place.

<comment><USER29> Money is probably the most persuasive tool we have as a society to change behaviour. Yes engineering is vital but it works with economics not in isolation.

<comment><USER30> I think the issue is who pays. If it ends up as consumer tax only it will take awhile before change is reflected. A business tax would accurate change.</comment></comment></comment>


Non-intuitive Examples of Compounding Returns - <AUTHOR> http://blog.futureadvisor.com/42555581

<comment><USER2> Of course, nobody can reliably get 5.04% after tax and after inflation compounding returns. (And nobody was able to over the long term in the Twentieth Century in passive investments.) If you put your money in the stock market over the past decade, for example, your return would be zero. And this is one of the best times to be cashing out. Most of the last decade would have produced negative returns.

Less risky investments like government bonds typically return less than 1% over inflation. If you intend to save for retirement and hope to benefit from compounding, you should be prepared to depend on 1% or less returns. One percent returns will double your money in seventy-two years.

If you want to retire on more than Social Security, you should be prepared to save every penny you'd like to spend. Compound investment returns have always been unreliable and the development of modern finance may have eliminated those returns forever by shifting all gains to banking executives.

Social Security is doing much better by comparison. Or you could get yourself a government pension; those are insanely generous.

<comment><USER3> The point of the article is sound nonetheless: it is better to save early and consistently.

This simple lesson alone could help many young people avoid financial issues later in life.

<comment><USER4> No, the "compound interest" meme is one of the most dangerous ideas that's going. Fundamentally, exponential growth destroys itself.

My model for economic progress is that there are two variables: the ability for a civilization to solve problems and the ability for a civilization to create problems. The benefits of growth are more immediately visible than the drawbacks, and because they differentially accrue to certain people, those people gain political power that is used to suppress the political response that would solve the problems created by growth. As a result, problems eventually grow faster than solutions.

When the ability of a civilization to create problems exceeds the ability to solve problems, we get an economic crisis such as the Great Depression, the stagflation of the 1970's or the situation that we're working through now. One way or another, the system needs a decade or so of low performance in order to slow down and sort out the problems that growth has created.

These crises seem to come every 40 years or so, so you're certain to have one, maybe even two, in the course of a career and subsequent retirement. And it just takes the aftermath of one to destroy your savings and possibly your career.

And, as the previous commenter says, if Wall Street has really turned into a system that captures all economic gains for a few people at the top, all you're doing is making them rich when you put money in a 401k or IRA. Personally, if I was President, the first thing I'd do is dismantle the 401k and IRA systems and let people withdraw all the money they have in them.

I'm convinced that tax-deferred savings have created a 'lost generation' of small businesses. It used to be people stacked up money in a bank and had it available when they wanted to start a business. If all of your savings are in a tax-deferred savings plan, you deprive yourself of that option.

</comment></comment></comment><comment><USER5> There are lots of articles like this. They seldom discuss the effects of inflation or properly plot things out on a logarithmic scale.

<comment><USER6> I agree about the effects of inflation, but why should things be plotted on a logarithmic scale?

<comment><USER7> If you have constant return (e.g. 5%) this will show up as a linear growth function on a log scale. It will be exponential on a normal scale, which over time gets very steep. Using a log scale allows you to compare the growth rates of different investments in a consistent way.

</comment></comment></comment><comment><USER8> I give this same advice a lot, and it's always telling to watch people's reaction. Human nature is all about defending what you're currently doing, against all evidence that there's a better way.

So, yeah, it's impossible to get 5%? Are you sure about that? Over a 40-50 year period? You'd have to look pretty hard at old stock charts to find a spot where you could get overall returns that low.

And yes, inflation exists. It's probably still a good idea to save money for retirement though.

And yes, you're young and don't have as much money to spend. But you also are coming off a lifestyle where you shared a room with six guys and ate Costco ramen every meal for 4 years. As soon as anybody starts giving you money, it's money you didn't have before, so you absolutely can find a way to save it.

It's a lousy $1,000 per month. Figure out a way to stuff it into the market, and despite all your rationalizations, the 50 year old version of you will thank the 22 year old you.

<comment><USER9> Yeah, I've tried the whole stock market thing twice now. Put $1,000 in as a tracker against the market index, expected a decent return; of course, I put it in on Sep 10, 2001.

Never got that money back.

Thought I'd try again a couple of years ago, so I bought shares in Lloyds Group. On the eve of Lehman going south.

Never got that money back, either. I think I'll stick to 3% savings accounts, thanks.

<comment><USER10> Where's a 3% savings account?

<comment><USER11> From the mention of Lloyds I'll assume that Two9A is in the UK. The best instant access savings I know about is 2.9% from the post office [1] with better rates available for 1 year bonds or longer [2].

[1] [http://www.postoffice.co.uk/portal/po/content1?catId=1930023...](http://www.postoffice.co.uk/portal/po/content1?catId=19300232&mediaId=126000768) [2] <http://www.lovemoney.com/savings/term-bond-accounts.aspx>

</comment></comment></comment></comment><comment><USER12> While this graph is indeed accurate for a static income, for many people the income will increase over the years (on top of the inflation) which will cause difference to be a little less dramatic.

Regardless, save as much as you can as early as you can...

</comment><comment><USER13> This is so great in theory, I've ran the calculations over, and over again. However I feel like the question marks are never filled in.

1.) Put 1k a month in savings 2.) do ??? 3.) get > 3% compound interest 4.) enjoy a debt free lifestyle

where do i get > 3% return!</comment>


Multiple Static Analyzers are not enough - <AUTHOR> http://freeradius.org/security/fuzzer-2017.html <comment><AUTHOR> I submitted this with a different title from the web page to get more attention to the issue. Not many people care about FreeRADIUS. I suspect there will be more interest in the underlying issues.

We run FreeRADIUS through four different static analysis tools, and have hundreds of regression tests. After the OpenVPM issues recently, I asked Guido Vranken to look into FreeRADIUS.

In short, fuzzing and address sanitization found about as many security issues as were found by all other techniques in the last 10 years.

 _Everyone: Please use fuzzers and address sanitizers on your C code. It will find things._</comment>


Live coverage of the final projects at NYU ITP - <AUTHOR> http://backspac.es/tag/itp

<comment><USER2> nice. thx for this. was wanting to see some on the ground looks at what's goin on here.</comment>


No Copyrights on APIs: Help Us Make The Case - <AUTHOR> https://www.eff.org/deeplinks/2012/11/no-copyrights-apis-help-us-make-case <comment><USER2> I don't buy the SAMBA example in the original article. As I understand it they reverse engineered the API/protocol from the on the wire network traffic. This would to me make it not a case of literal copying and therefore not infringing a copyright in the API (if it exists).

The equivalent for a general API would be avoiding the documentation and the actual API files (headers etc.) and developing an alternative implementation from examples of client code and the behaviour observed of the library when tested with inputs.

This may be the answer, allow APIs to be copyrighted (in general - some may be too trivial to be copyrightable where there are limited sensible approaches) but allow the reverse engineering of behaviour.

Of course it would be possible to grant licenses to the the API and it may be sensible to consider the flexibility of the API license when choosing to use a library, webservice or framework and the difficulty of transferring away from it to an alternative supplier.

<comment><USER3> It's much less ambiguous to exclude APIs from copyright. Otherwise, you'll have endless battles trying to prove that someone really _did_ have access to the API documentation, or some derivative work thereof. Or, someone will argue that reverse engineering an API should not be permitted.

On the flip side, API copyrights could be rendered moot by simply reverse engineering everything, which isn't really that hard.

<comment><USER4> This is correct, doing away with API copyright all together is only solution.

<comment><USER2> 'only solution' that is a very absolute response, is there not even room for discussion? I would have downvoted you if I could and I have upvoted comments I don't agree with in this thread that added depth and thought to the discussion.

Secondly exactly what is it a solution to?

Have you considered any possible costs or downsides to the proposal?

</comment></comment></comment></comment><comment><USER5> I thought APIs had been established as non-copyrightable by numerous precedents, e.g. Lotus v. Borland, Apple v. Microsoft. Why do we need to go through this again?

The US Copyright Law Chapter 12 provides for reverse engineering, for the purpose of interoperability. So that would seem to negate any defense of copyright of an API, whose sole purpose is interoperability.

</comment><comment><USER6> Honestly if something is silly as several musical notes can be copyrighted, I don't see how you could argue something as complicated and full of creative work as an API can't be. Instead, I think we need something more like the reverse-engineering or parody laws. Allow them to be reimplemented as long as it is clearly called out that they are not the original creative work of the reimplementing party. It would lead to effectively the same thing and would give the original creator credit.

<comment><USER7> That isn't how the "fair use" defense for satire (not parody!) works, nor is that the purpose of it.

And it is unclear that an API is full of creative work in the sense of what copyright covers. JK Rowling could have written the Harry Potter books in the first person and still told the same story, but she chose not to. Books are full of all sorts of choies like that. But if you change an API, it is no longer the same API and no longer capable of interacting with a program that implements the original API. There is no room for creativity, because differences are _functional_. Copyright doesn't cover function — that's what patents are for.

This isn't to say that APIs can't be well designed or poorly designed — just that insofar as they are mere information about how you interact with a system, they are not copyrightable. Information is not copyrightable.

<comment><USER2> I have some sympathy for this argument although in what way does this argument that the creative expression in API design is functional and therefore uncopyrightable not actually apply to all software? I'm not sure that leads us to a good place as that would only leave patents to protect software.

<comment><USER8> If you change the API design in any way, it no longer fulfills its purpose - interoperating with other software that uses that API. Hence, API design is functional.

However, you can change the design of a piece of software (for example, a user interface) while having it still be able to fulfill its purpose. So in the general case, software design is not necessarily strictly functional.

<comment><USER2> I up voted both you an AnthonyMouse for good clarifying comments that move the debate forward.

Do you think it is then legitimate to partially copy an API making sufficient changes for it to be largely incompatible (certainly not a drop in replacement)? In this scenario the functional element is lost in the copy but not the creative element.

<comment><USER9> I assume you're referring to what Google did, i.e. implementing a subset of the API but not the whole thing. But in that case I wouldn't agree that the functional element is lost. It continues to exist exactly to the extent that they copied the API -- the functions they copied are compatible. Any code using those functions will compile against both. (Incidentally, it feels like a very strange argument for Oracle to say that the problem with what Google did is that they didn't copy _enough_.)

I suppose you could argue that it's theoretically possible to copy the creative elements from an API while specifically setting out to break _all_ compatibility, but it's hard to say what that would even look like. You can't break compatibility without changing the function signatures, but if you change substantially all of the function signatures then it's arguably a completely independent API. More importantly, it seems like this would be more of a theoretical problem than one seen in practice -- the only practical reason to copy an API is to achieve partial or complete compatibility. Can you provide any example of an API being copied for reasons other than achieving compatibility?

<comment><USER2> What Google did is an interesting example but at least jbri's comment referred to breaking functionality if you changed it at all so it needed to be copied.

Oracle did make the point that Google didn't copy enough for compatibility and Write Once Run Anywhere effectively forking their entire ecosystem/platform without a license. It has killed Java on mobile (although maybe it would have happened anyway and maybe it is a good thing with Oracle running the show). I think that if the participants in the case hadn't been the most hated and loved companies in tech many people might have had a different view of the case.

There are a number of other reasons for copying an API than compatibility.

1) Its an efficient (lazy?) way to get to a well designed API without you having to do multiple rounds of iterative design as users hammer on it over several years.

2) Existing documentation can be used. [Documentation, tutorials StackOverflow answers].

3) Users are already familiar with it.

It seems to me that Google did a pretty vicious embrace, extend, extinguish on mobile Java and they may still be the better custodians of the platform but I'm not sure the behaviour is actually acceptable in general. They took maximum benefit from Sun's efforts to create a platform and a community and give the absolute minimum back. Just imagine if it was Microsoft (or even Apple) in the Google roll and old Sun (rather than Oracle) in the Oracle roll - would you still feel the same about the case?

Now does this mean I want to be locked into a provider unable to find an alternative implementer of a required library - absolutely not. But that is a factor to consider when adopting a platform/library as a cost to be weighed against the benefits. I always like an exit option or accept significant risk if I don't have one. Obviously API developers could offer permissive licenses to the API even if the library itself is closed source as a way to reassure customers and gain business. I'm not sure law is required OR desirable in this area.

<comment><USER9> >There are a number of other reasons for copying an API than compatibility.

All three of the ones you listed are just advantages of compatibility. You don't get any of them exactly to the extent that you aren't compatible.

>Just imagine if it was Microsoft (or even Apple) in the Google roll and old Sun (rather than Oracle) in the Oracle roll - would you still feel the same about the case?

Sure. Because the problem you're implying would occur is completely different to the question of copyright over APIs. People object to Microsoft's EEE because it's anticompetitive -- if it's to be illegal then it should be as an antitrust violation, not a copyright violation. Which is why many people don't object to what Google has done -- they're not using it as lock in. It's open source and you can port their VM to whatever platform you like and run all the same user code. The only reason you can't run all the Android apps on an iPhone is that _Apple_ doesn't allow it. I believe RIM actually offered it as a feature for about five minutes before they realized they also used Oracle Java(TM) and were too busy going out of business to be fighting with Oracle over license terms.

Moreover, it's bad policy to allow copying when the implementation is perfectly compatible but not when it isn't. It says to the small developer that they can't just patch Kerberos to do the thing they need to talk to Microsoft software, they have to reimplement all of Active Directory. And if the implementation adds anything useful then it's not compliant and they're infringing copyright. Ditto if there are any bugs or the reimplementation lacks bugs present in the original.

API forks are not inherently evil. Making them copyright violations makes them inherently prohibited. Better to prohibit the things that actually are evil, like EEE for anticompetitive purposes.

<comment><USER2> > All three of the ones you listed are just advantages of compatibility. You > don't get any of them exactly to the extent that you aren't compatible.

But you are definitely getting beyond it being a pure functional issue. Lots of other things can also be made easier without copyright.

Competition law may prevent the worse abuses but I expect not all and it can be terribly slow.

> API forks are not inherently evil. Making them copyright violations makes > them inherently prohibited. Better to prohibit the things that actually are > evil, like EEE for anticompetitive purposes.

Copyright in general is not a matter of inherent evil but a balance of rights. I also agree that forks are not always a bad thing but they could be permitted by the copyright holders (if API's are copyright).

The benefit of copyright is incentive for investment and creation. I have general issues about current copyright duration and the limits on circumvention and fair use/dealing but I'm still not convinced about the general benefit of non copyrightability of API's.

As I said the lack of a relatively permissive license over the API would put me off using it unless I had another exit strategy (easier for a simple library than for a massive framework like Java but the investment is smaller in creating a simple library).

<comment><USER9> >But you are definitely getting beyond it being a pure functional issue.

How so? Creating a compatible piece of software is _functionally impossible_ without using the same API, because that's what the API is. You can't do it. The fact that compatibility has a lot of advantages doesn't change the nature of that functional necessity.

>Copyright in general is not a matter of inherent evil but a balance of rights.

Of course, but that's the point. You weigh the evil against the good. If someone creates a thing and is a good steward of it then they have a first to market advantage over competitors in addition to the implementation copyright, so as long as they're being good stewards and only collecting their creation costs plus a fair profit, they'll have the market all to themselves because prospective competitors will see that they can't profitably do any better as against the need to spend the resources to create another implementation. Only when a copyright holder is allowing the market to decay or imposing unreasonable restrictions or pricing on users will there be a sufficient incentive for others to enter the market, and why in that case does it make any sense to give the copyright holder the power to prohibit such competition?

>I also agree that forks are not always a bad thing but they could be permitted by the copyright holders (if API's are copyright).

The problem is that in almost all cases the copyright holder wouldn't allow it -- a full reimplementation fork is only necessary when the existing maintainer is doing such a sour job of it that you think you can justify the enormous reduplication of effort necessary to compete with them, and in that case why would they sanction a competitor?

<comment><USER2> The items like people's knowledge and documentation are not purely functional.

You might be a good steward but with high prices due to the education costs you take on teaching the API to others. Someone can piggy back on your work, charge a lower price and never do their own further design work.

You can compete without copying the API, just design your own or use an open source one. Yes it would be hard for people to switch libraries when they have existing code but it is possible to rewrite the client software.

It is allowed by many copyright holders. Virtually all open source software and a number of other commercial platforms particularly when the API has been designed or released by or to an industry consortium.

I see it as a perfectly valid reason not to choose a platform with a closed API and while I feel sorry for those that are locked to one theynreallynshould have considered it at the start. I still don't see it as an essential issued.

I've enjoyed this conversation but I suspect no one is watching apart from us so while I wanted to answer your questions so as not to be rude and ignore them I plan not to post again on this thread.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Any creative content or writing can be copyrightable. But in the case of _Oracle vs Google_ , the end of the case was that an API is just no more than a list of rules and URLs, nothing "creative".

And a list is not copyrightable.

Think to the Yellow Pages for examples. No Copyright on name, address and numbers (hopefully) , because no specific form or shape to these writings.

The case is to define if design an API is more than listing URLs. I don't think so, and the Judge Alsup of _Oracle vs Google_ who was developer too, said the same thing.

But API providers will try to not accept this. Do you remeber Twitter's message to developers

[http://apijoy.tumblr.com/post/34350096121/twitter-api- teams-...](http://apijoy.tumblr.com/post/34350096121/twitter-api-teams- message-to-developers)

?

IFTTT, Zapier, Webshell.io, Webscript.io, Elasctic.io, Apiary.io, Opalang.org, Rules.io etc...we have something to bring to firstname.lastname@example.com

</comment><comment><USER11> _2\. Reimplementation of an API, where the resulting software benefitted the original API creator, perhaps by increasing the creator's user base or otherwise benefitted the developer community._

Would this cover a language-specific wrapper around an HTTP API? For example, I wrote a Python library for the iHackerNews API[0]. Would something like that count as a reimplementation for the purposes of their request?

[0] <https://github.com/dmpayton/python-ihackernews>

</comment><comment><USER12> Some thoughts on why a legal precedent probably isn't enough: [http://www.3scale.net/2012/11/the-case-against-api- copyright...](http://www.3scale.net/2012/11/the-case-against-api-copyright- and-the-need-for-an-interface-commons/)

</comment><comment><USER13> this would be a stepping stone to copyrighting design patterns ... _shrug_</comment>


How to Make Money: 40+ Ways to Make Extra Money to Boost Your Income - <AUTHOR> https://www.mybreadmoney.com/make-money/ <comment><USER2> Before I click, is this worth reading?.. or is it going to be another one of those:

1: Sell things you don't need on eBay 2: Write a really popular blog and sell advertising 3: Create a really popular Youtube channel and sell advertising 4: Design a popular app and sell it 5: Do odd jobs for people for money ...etc.

lists

Which is what these articles usually amount to and which are about as much use as advising folks to "Win the lottery!"</comment>


Webpack 3: Official Release - <AUTHOR> https://medium.com/webpack/webpack-3-official-release-15fd2dd8f07b <comment><USER3> My favourite part of the Webpack 1->2 transition was when they updated their old documentation to say that Webpack 1 was deprecated [0], but failed to mention if the user was currently looking at the Webpack 1 docs or the Webpack 2 docs!

I ended up reading the Webpack 1 documentation for several weeks after 2 came out. I'd see the warning, go "oh, I better not use Webpack 1 then", and continue reading its docs. Cue lots and lots of head scratching.

Webpack developers: if you're going to release a new set of documentation for 3, then please, please make this clear.

[0]: For example, [https://webpack.github.io/docs/code- splitting.html](https://webpack.github.io/docs/code-splitting.html). "webpack v1 is deprecated. We encourage all developers to upgrade to webpack 2." There's a link, sure, but I didn't follow it because I had no reason to think I wasn't already on the Webpack 2 docs page. _grumble grumble_

<comment><USER4> When I google for "webpack someproblem" then the the first results are usually pointing to the webpack 1 docs. I often don't even find documentation for webpack 2 on the first page, unless I explicitly search for "webpack 2". It took me some time, but now I'm always appending the version number to all my searches. I think Angular has/had the same problem.

Edit: and luckily it's easy to discern the webpack docs: v1 docs look ugly and are lacking information, v2 docs look much nicer and are more detailed ;) They did a great job so far improving the documentation.

</comment></comment><comment><USER5> I'm kind of surprised how cold reactions are against Webpack here on HN. I consider Webpack by far the best module bundler. My path was: scripts, stealjs, requirejs, requirejs + grunt and also recently tried SystemJS. All of them are pretty awful. Try one of those and you'll realize how amazing Webpack is. For example one of the newer bundler - SystemJS pretty much force you to use jspm package manager. Jspm changes SystemJS configuration on every new package installation, so you can be never sure, if build is failing because jspm changed something. You can forget on imports without providing correct extensions (js,jsx,...), or prepare to fill you config will lot of defaultJSExtensions/file mapping. Also import Module from './module where module is folder with index.js file doesn't work out of the box and mapping has to be added. etc... The only thing I'm personally missing in webpack, is option to provide custom chunk loader, so I can load chunks with any other AMD loader, something similar to requirejs+almodjs or SystemJS static SFX builds, which was the reason I've tried SystemJS at first place, but it wasn't worth the pain.

<comment><USER6> Have you tried rollup? Webpack's tree shaking is broken and doesn't work properly with libraries structured like d3, while rollup's works properly. I've managed to get trivial 150kb minified size reductions by switching.

<comment><USER7> But isn't Rollup.js directed at libraries whereas Webpack aims for JS apps?

<comment><USER8> I use Rollup for both, though I don't remember exactly how, as I made a project out of my build setup: [https://capnmidnight.github.io/marigold- build](https://capnmidnight.github.io/marigold-build)

</comment></comment></comment></comment><comment><USER9> Every time I start a new project, I try using latest webpack first. Result is always me getting frustrated and replacing it with simple `browserify` call with couple of `--transform` flags.

Recently I tried bootstrapping it with `create-react-app` and ejecting, so I can modify webpack config. `yarn start` kept linting something deep inside `node_modules`, and failing for some nefarious reason even after linting step was removed completely from everywhere I could reach. `build` command work fine, though, so go figure.

Not sure if "magic comments" will solve my problem, but it surely is nice to have simple alternative, thanks substack and everyone behind browserify! [https://github.com/substack/node- browserify](https://github.com/substack/node-browserify)

<comment><USER10> webpack is just more complicated, which means it takes longer to start - <USER2> also has some bad naming and quirks which happens when design-by-committee decisions take place.

the webpack book by survivejs takes a few hours to read completely, or an hour to read the important parts, and you'll be very comfortable with it.

[https://leanpub.com/survivejs-webpack](https://leanpub.com/survivejs-webpack) or [https://survivejs.com/webpack/preface/](https://survivejs.com/webpack/preface/)

<comment><USER11> > the webpack book

Holy shit, I thought you were kidding.

We're at a point where the bundler, one of a dozen elements required for a 'barebones' modern js application, needs a _book_.

I'm finding it hard to find motivation to do any kind of web based side projects these days because they inevitably begin with 'which combination of latest and greatest libraries do I need to spend an entire day wiring up before I can do hello world this time?'. Someone make this madness end.

Modern javascript tooling makes 90s C++ look pretty pleasant.

<comment><USER10> You can write a book about anything and it's also a great way to learn so not sure why that is an issue.

webpack does a lot so it requires lots of knowledge -- or you could just stick to script tags and basic minifiers built into every server side web framework at this point.

npm (or yarn) for downloading dependencies + webpack to squeeze them into a bundle makes for a very powerful combination _if you need it_ and it takes a few mins at most to setup. Why the hyperbole if you don't understand it?

<comment><USER11> > takes a few mins at most to setup

Now there's hyperbole.

Let's be honest. Unless you do it for a living, at best it takes a few hours to set up boilerplate for any modern js project today.

And let's also be honest that es6 is a must today and script tags are not an option until browser es6 support is ubiquitous.

Last project I set up, grunt and browserify were _the thing_. You were an idiot if you weren't using them. Apparently now it's webpack and gulp. In another year it'll be some other crap. The first step to dealing with a problem is admitting there is one. I'm not sure labeling comments that highlight the problem 'hyperbole' is constructive in any way.

<comment><USER12> Can't you just use a project starter script and get it set up in minutes?

<comment><USER11> Which one?

The one with webpack? 1? 2? Now 3?

What about react? And redux. And react HMR. Oh and you probably need immutable.js if you want to use react the 'proper' way not like those fools last year. Your starter script was configured with react-router? That's a shame, because it's no longer the latest and greatest, and everyone knows you should have moved on to React Mini Router. Or is it React Universal Router now? Wait is the particular configuration of webpack in this starter script even compatible with the latest and greatest babel-loader? Hang on, you wanted to use promises? Yeah, that's another plugin for polyfill and more config that interacts with most of the above. Don't worry though, there's plenty of tutorials to get it working with webpack... Oh wait, they're all for webpack v1 and you're on v2.

<comment> aaron-lebo So don't upgrade to the latest and greatest tech? Find something that works and use it just like anything else.

Is your complaint really that there's new tech out and you have the option to use it? Do you complain every time a new language releases? Do you use Django 1.2 because you don't feel like upgrading to 1.3, 1.5, 1.8?

I don't exaggerate in saying that the comments you've posted in this thread have taken more time than it would take to have a basic webpack setup.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> In semver land, every major release is a tragedy. I love that they're really doing hard (and free!) work to make the transition as smooth as possible, but I still wish the JS ecosystem culture would be more conservative about releasing breaking changes.

<comment><USER14> From the article:

Migrating from webpack 2 to 3, should involve no effort beyond running the upgrade commands in your terminal. We marked this as a Major change because of internal breaking changes that could affect some plugins. So far we've seen 98% of users upgrade with no breaking functionality at all

<comment><USER13> Your point being? The plugin interface is a public interface too, right?

Again, I really appreciate all the work done to make this smooth, but there's still a little underlying "compatibility matters less than features" sentiment here.

<comment><USER15> > The plugin interface is a public interface too, right?

It didn't say 'plugin interface'. It said 'internal changes' that could affect some plugins. The way I read that is some plugins could be relying on internals (that they technically shouldn't, they may have good reason ofc).

</comment></comment></comment></comment><comment><USER16> Having gone through script tags -> Browserify -> Webpack, I now have the sneaking suspicion that Google's Closure compiler was the right thing all along, and that I should have learned that to begin with.

</comment><comment><USER17> I used both and still prefer Browserify. No configuration required, it just does what you want. Also its source code is quite short and easy to grok.

</comment><comment><USER18> Thanks to the Webpack people for focusing on ease of use, ease of migration and avoiding breaking changes.

react-router has recent gone from version 3 to version 4, which is essentially a completely new and almost unrelated piece of software to V3 and requires a major rearchitecture of your application to make the transition. In effect it is one big breaking change.

<comment><USER19> Upgrading from 3 to 4 is not required. Version 3 is still maintained. It's not ideal since there will probably be no future major 3 versions, but no one is forced to make a 'big breaking change' strictly speaking.

> We intend to keep supporting the 3.x branch indefinitely (published > separately on npm to aid in migration), although there will likely not be > any future major versions based on that code. 4.0 is the future, but we > won't leave you hanging if you want to stick with 2.x/3.x.

[https://github.com/ReactTraining/react- router/releases/tag/v...](https://github.com/ReactTraining/react- router/releases/tag/v4.0.0-0)

Previously discussed here: [https://news.ycombinator.com/item?id=12511419](https://news.ycombinator.com/item?id=12511419)

<comment><USER20> 4.0 is a regression imo. The docs say that if you do server side rendering with code splitting then 'God Speed' (their words not mine).

I don't see the benefit of switching if v3 allowed me to ssr and code split while v4 doesn't allow me to do both.

From the user pov it went from instantly displayed page with minimal js required to choosing one of those options.

What benefits could exist that supercede giving the user the best possible experience? (Genuine question).

I can't imagine huge speed gains going from one page to the next from this change and indeed changing pages in SPAs are essentially instant. So what could possibly be better that makes it worth getting rid of ssr and code splitting? Imo I won't be using react-router in future products because they are too fickle with their codebase.

<comment><USER21> This was the madness that finally pushed me over the edge and towards Vue about 8 months ago. No regrets here!

</comment></comment></comment></comment><comment><USER22> Nice, I noticed the push earlier tonight on github and tried upgrading to 3.0 in the project I was working on, but I guess it was a little too soon and I ran into dependency errors.

Here's to hoping that we see a performance _increase_ instead of a performance _decrease_ as was the case with 2.0.</comment>


Nation Will Gain by Discussing Surveillance, Expert Tells Privacy Board - <AUTHOR> http://www.nytimes.com/2013/07/10/us/nation-will-gain-by-discussing-surveillance-expert-tells-privacy-board.html?_r=0&gwh=C1115C6748940FD3A1A581765F7FAE70 <comment><USER2> I have a modest proposal.

All FISA court decisions are published, with identifiers (names, IP addresses, country names, etc) redacted, after 10 years. After 30 years, unredacted copies are published.

This lets us know the scope of the spying. This allows for public feedback to let the FISA court know what people do. This lets everyone - including our intelligence services - understand that there are real consequences to spying on allies, and we shouldn't do it when they don't want it.

For those who complain that this limits what we can do because revealing our programs will upset allies, I would point out that history shows that programs tend to get revealed anyways. Therefore we should assume that people will eventually find out what we are doing, and not do things that are objectionable. Having an explicit timetable keeps our secret agencies from continuing to repeat this elementary mistake.

<comment><USER3> I like the idea (though I might limit disclosures of spying on a country $FOO to countries with a bilateral agreement not to spy back or to be similarly transparent).

I don't think it addresses the concern of capturing haystacks before we know which needles to look for but it would certainly help with transparency. Even more importantly, it ingrains in the mind of the analysts actually using these systems within the intelligence agencies, and the FISC itself, that there is that concern for eventual public disclosure. Therefore, they should be inherently suspicious of anyone trying to avoid adding a given FISA warrant to the public disclosure list, or otherwise trying to interfere with public disclosure (such as by going around FISA).

And as I've mentioned before it would be even better if this kind of thing were _built-in_ to the systems themselves so that an analyst or their supervisor couldn't choose to 'forget' to do it.

</comment></comment><comment><USER4> I agree that this discussion needs to remain at the forefront of our collective thoughts and discussions.

We have an awful tendency to forget these things, and as the old saying goes:

 _He who forgets the past is doomed to repeat it._

</comment><comment><USER5> Is their issue with spying only about how much oversight there is, and not with the US government having full and complete access to the underwater Internet cables like some kind of totalitarian government?

As long as they can still do that, you still can't trust anything they say or any of their "policies". Also what will happen with the Utah data center now? Will it be turned into a dairy? Or will the NSA be free to use it just as originally intended?

I believe governments need to go back to what they were always supposed to do - investigate _specific_ targets, without having access to everyone's data in order to do that.

Also there should be _no_ ties between the NSA and FBI. None whatsoever. If there's an urgent national threat, the NSA should report to the president, and then the president can contact the FBI about it, allow them to collaborate in some way. But that's it. The policy/law should be very clear about the circumstances in which they are allowed to do that.

Otherwise, I fear in many cases the info NSA is getting is later used by the FBI as "probable cause", to later get (constitutionally legal) warrants to investigate someone - when it was just a fishing expedition all along.

<comment><USER6> Agreed. Considering the NSA stores the contents of all our electronic communications (including phone calls), they have a massive pool to fish in. What will they fish for next?

Edit: You know who's in that pool, alongside us? Senators. Congressmen. Police. Other spy agencies.

<comment><USER7> And journalists and political activists.

<comment><USER8> And millions of us foreigners with absolutely no vote on anything.</comment></comment></comment></comment>


Sorbet: Gradual typing of Ruby at Scale - <AUTHOR> https://sorbet.run/talks/StrangeLoop2018/#/ <comment><USER2> They've shown this quite some time ago, but it still didn't go further than the cute online demo, unfortunately. Really hope they release something tangible to play with.

</comment><comment><USER3> If you didn't go through the presentation, the plan is to release Sorbet as an open-source product in 2019.

<comment><USER4> I don't think anything in the presentation suggests they're making this a product does it?

<comment><USER3> The shared timeline? What do you define as a product, btw. Is "rubocop" a product? - I'd say, yes. I'm sorry if I've confused you.

<comment><USER4> I thought 'product' meant something commercial - something with an income. I'd say Rubocop was a project but not a product.

</comment></comment></comment></comment><comment><USER5> I love the idea of gradual Ruby typing but I think I'm going to wait until Matz follows through with his promise to bake it into the language.

But if I were working in a shop that was considering moving off Ruby and this would convince them to stay on it, I'd very happily adopt it.

<comment><USER6> Matz has stated that it's unlikely to happen for years (2040 was mooted recently). So, your strategy is more likely to leave you with a less scalable and more buggy code base for years to come.

Sorbet is compatible with existing Ruby, requires no syntax changes and can be transpiled into whatever official typing support comes into existence many years from now.

Give it a try, it's good for you :-)

<comment><USER7> > Give it a try, it's good for you :-)

Can we actually try this though? 2019 appears to be the planned open source date.

</comment></comment></comment><comment><USER8> This is interesting work, of course, and highly valuable ot existing Ruby codebases & organizations. But I do wonder if the interest in this among current Ruby shops suggests to anyone that choosing a different language/runtime for new development is best?

</comment><comment><USER9> The StrangeLoop video is not posted yet, but you can see a related video from RubyKaigi here: [https://www.youtube.com/watch?v=eCnnBS2LXcI](https://www.youtube.com/watch?v=eCnnBS2LXcI)

</comment><comment><USER10> Interesting</comment>


How Libcorrect Corrects Errors, Part I - brian-armstrong http://quiet.github.io/quiet-blog/2018/09/16/How-Libcorrect-Does-Forward-Error-Correction.html <comment><AUTHOR> So there's the phenomenon of bit rot. Filesystems like ZFS add data checksums, and they recommend you to scrub the data once in a while, and then when errors are detected you are supposed to restore from a replica/backup (whether restoration happens automatically or manually is besides the point; the point is that a replica/backup is required in order to restore).

Why can't error correction codes be used instead of replicas/backups, as the primary means to recover from bitrot? (NOTE: I am talking about the _primary_ means; obviously a backup is still necessary for more serious forms of disaster recovery. I am not advocating abolishing backups altogether) That makes it a lot easier for single-disk use cases, e.g. laptops or consumer devices. It also saves space, which is also important because laptop SSDs and phone SD cards aren't that big. A replica doubles the space requirements, while an error correction code is smaller than that.

<comment><USER2> > and then when errors are detected you are supposed to restore from a > replica/backup.

ZFS will recover/self-heal from errors if it can definitively figure out which data is correct.

many storage technologies do protect against errors, CD/DVD/HDD all have ECC in the physical layer. but without control/knowledge of the physical medium (so at filesystem level), how do you distribute the ECC sensibly? you can't.

another issue is if the other hardware doesn't do ECC, for example with non- ECC RAM. RAM is arguably more susceptible to bitflips due to it's dynamic nature. can you recover from errors if the information in your RAM can't be trusted? it's a hard problem, and ZFS pretty much requires ECC RAM for any data integrity guarantees to work.

it also doesn't necessarily matter. a single bit flip in e.g. a jpg or mp4 file doesn't necessarily render it unusable, so people don't care.

finally, ECC is a bit useless if your whole drive or device fails, which is a much more common failure mode.

storage is cheap nowadays, and even double or triple redundancy is cheaper and more straight-forward than trying to be clever.

<comment><AUTHOR> > how do you distribute the ECC sensibly? you can't.

I am not an expert on ECC. Are you saying that you can't store the ECC just anywhere? Just storing it alongside the data is not good enough? Why does ECC need special treatment?

> storage is cheap nowadays, and even double or triple redundancy is cheaper > and more straight-forward than trying to be clever.

Tell that to Apple to who charges $500+ for a 1 TB SSD upgrade in a Macbook Pro. :-( "Cheap" is relative. I am worried about bitrot on my laptop but I also don't want to half my disk space in order protect against that.

<comment><USER3> > > how do you distribute the ECC sensibly? you can't.

> I am not an expert on ECC. Are you saying that you can't store the ECC just > anywhere?

Well, you can put it "just anywhere", but /where/ you put it determines /what failure types/ you can recover from.

> Just storing it alongside the data is not good enough? Why does ECC need > special treatment?

If you want to recover from bitrot, then putting the ECC data for a sector alongside the data in the same sector is sufficient (you'll have less bytes stored per sector, but if a bit flips, you can recover the original data).

But, storing the ECC in the same sector with the data it protects will not protect against losing the entire sector (drive can't read whole sector error). In this instance both the data and the ECC is lost simultaneously, so the ECC can not help here if it is also lost at the same time. So if you want to protect against loss of a sector you need your ECC stored somewhere else (i.e., on a different sector that is unlikely to be correlated to the lost one in a failure situation) so that you still have the ECC available when the sector you are protecting goes away.

But, if you are protecting against loss of an entire physical drive, then the ECC for the drive needs to be on another physical drive (same reasons apply as for a "sector", just at the level of a whole physical disk).

It is all tradeoffs. You /can/ put it anywhere, but where you choose to store it determines which failure types you can recover from.

<comment><USER4> Disk drives use sector-level ECC, silent sector corruption should be (and IME is) more rare than unrecoverable sectors.</comment></comment></comment></comment></comment>


With Plan X, Pentagon seeks to spread U.S. military might to cyberspace - <AUTHOR> http://www.washingtonpost.com/world/national-security/with-plan-x-pentagon-seeks-to-spread-us-military-might-to-cyberspace/2012/05/30/gJQAEca71U_story.html

<comment><USER2> I have a vision of a bunch of the heads of _other_ secret projects going "Awww, why do _they_ get to be Plan X? I wanna be Plan X!"</comment>


The Rise and Fall of Thinking Machines: a doomed-yet-brilliant start-up - <AUTHOR> http://www.inc.com/magazine/19950915/2622_Printer_Friendly.html

<comment><USER2> I have a few friends who've done time here: <http://www.imagination- engines.com/>

From what I understand, though, that's an almost totally crackpot operation.</comment>


Toward Modern Web Apps with ECMAScript 6 - <AUTHOR> http://www.sencha.com/blog/toward-modern-web-apps-with-ecmascript-6/ <comment><USER2> A better title would be "Towards old age, waiting for ECMAScript 6".

It's only been like 10 years already (since those features were promised for ES4), no need to move faster, please participating companies, take your time debating BS pedantic distinctions until the spec is finalized. Then it would only take 3-4 years until it has around 90% penetration so it can be used.

It's not like 14-15 years is a lot of time in technology. Perhaps only one generation of web programmers will have retired by then.

<comment><USER3> The issue being, of course, that a standard which is not implemented is of little use.

Last time around, a few stakeholders (mostly MS, but also Yahoo and Google) managed to railroad the proposal completely resulting in the watered down ECMAScript 5.

<comment><USER4> But this is the sort of basic functionality that shouldn't be coming in a standard nearly 20 years after the language was first released. This is especially true when other languages have had such functionality since before JavaScript was conceived. It's not like they're new concepts that post-date JavaScript's creation.

<comment><USER3> Sure, but it's not like that's a rare occurrence (behold HN's darling Go)

</comment></comment></comment></comment><comment><AUTHOR> Here is a list of current browser support for ES6 features: [http://kangax.github.io/es5-compat- table/es6/](http://kangax.github.io/es5-compat-table/es6/)

<comment><USER5> I think the chart needs updating -- generators landed in Chrome, which is why they're in Node Harmony.

<comment><USER6> I actually am using them in a production node.js server so it better has support =)

</comment></comment></comment><comment><USER5> I'm expecting top comments will wind up being a bit negative because of how long it takes to modify a living language without breaking the web (spec side). But for ES6, the main thing in need right now is C++ programmers able to hack on VMs to actually implement all the features. If you are one and care about this, by all means see where you can help in V8/SM. If you're a company that cares but only has dollars, and not programmers/time, consider hiring consultants to work on landing the features you are most interested in. Just because a spec is fleshed out by committee over time doesn't mean the patches magically appear with it. (e.g. C++11)

<comment><USER7> Relevant: [https://code.google.com/p/v8/wiki/Contributing](https://code.google.com/p/v8/wiki/Contributing)

</comment></comment><comment><USER8> So... CoffeeScript with curly braces?

On a more serious take: as a Node.js developer I can't wait for generators to be ubiquitous!

<comment><USER9> CoffeeScript is a debauchery of JS. With ECMAScript 6 you won't need CoffeeScript for anything except maybe it's inline printf-like string substitution.

<comment><USER10> Coffeescript saved JS dev. It proved we did not have to wait for TC39 lto get new language features.

<comment><USER6> Meh. It doesn't even support getters and setters.

<comment><USER11> Don't use "objects". Embrace the associative array that is a JSON (I know, Object is in the name) construct. Getters and setters are not necessary with this.

<comment><USER12> How does using associative arrays reduce the need for non-trivial getters and setters? I see how it provides an alternative to _trivial_ getter and setter pairs; just as using bare public data fields in a language that supports them does, but non-trivial or non-paired (getter or setter alone) or different visibility ones seem to be a different issue.

<comment><USER11> My belief is that in a functional language like JS, you shouldn't couple data with operations on itself. As a result, all you'd ever have is non-trivial getters and setters. You see this with map like constructs in Erlang. You'd have a function that takes a map and does stuff.

<comment><USER13> Systems built with large teams need to have their developers negotiate API boundaries. Strict typing and intelligent getters/setters help a great deal to achieve this because the code becomes self-negotiating. A second problem with large teams is that most programmers can't write pure functional code, turning the codebase into a hybrid mess. ES6 matters most for large teams because the inefficiencies of ES5 are felt most on those kinds of scale.

I'm also doubtful how well DOM programming can be mixed with a functional approach, but i'll concede that it is at a minimum possible to do it.

<comment><USER12> I don't think it's true that most programmers can't write pure functional code; I think it is more the case that that most programming languages don't provide good support -- particularly constructs that make the distinction between pure and impure code clear -- for programmers who wish to write pure functional code or at least to cleanly segregate pure and impure code.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Will ES6 have native support for 64-bit integers and arbitrary-precision numbers? Or at least 64-bit integers? To me, this is the biggest, fundamental problem with Javascript.

<comment><USER15> Signed/unsigned 64-bit integers are on the agenda, but I think they are planned for ES7. They're being prototyped in SpiderMonkey right now.

<comment><USER14> That is great to hear! Of course if ES7 takes another 10 years...

<comment><USER15> I'm as impatient as you are :) Emulating 64-bit integers is pretty slow in modern runtimes...

</comment></comment></comment></comment><comment><USER16> More ways in which Javascript is sucking dramatically less from the language perspective.

<comment><USER10> front dev will always suck since Microsoft decided an entire generation of OS will never have a modern browser by default. And yes this is MS fault.

<comment><USER15> IE's been a solid HTML5 browser for a couple years now. As good as Opera or Safari, certainly.

<comment><USER17> Not really. There aren't regular updates to IE adding new functionality from the _living_ HTML5 standard (and other standards). Further, the latest IE cannot be installed on some older, yet still popular, versions of Windows. These two factors combined means that a lot of people don't have a modern up- to-date IE.

<comment><USER15> The current update frequency for IE is a dramatic improvement over older versions.

The fact that you can't install IE11 on Windows 2000 is irrelevant. I can't install Safari on my Windows machine anymore either, and it's still a HTML5 browser (albeit a bad one, the last time I tried it on a Mac).

Users not installing updates isn't relevant either.

IE is a perfectly respectable HTML5 browser. It runs my HTML5 games better than Opera or Safari and has fairly comprehensive support for non-bleeding- edge features, especially if you look at 11 (coming out soon, I believe).

<comment><USER18> > _The current update frequency for IE is a dramatic improvement over older > versions._ Obviously an update frequency of 1 year is a dramatic improvement > over an update frequency of 5 years, but still is not enough. Basically it > means "if a feature is not present in IE11, wait a year, or two".

</comment></comment></comment></comment></comment></comment><comment><USER19> the use of const in node.js at least can be used today and I think should be for all required modules... for example, it's always bothered me in node.js that most examples are written in the following way:

var fs = require('fs');

fs is such an easy name to give to any random variable in a function

function foo() { var fs = 88; // just overwrote fs module.. }

I do two things in my non-standard way...

const FS=require('fs');

it makes more sense to me... i'm less likely to write in a random function:

function foo() { var FS = 88; }

Just my thought... node.js supports const for a long time I wish examples would use it for required modules...

<comment><USER20> But your first example doesn't overwrite fs, it just overwrites the use within that function scope. Which is what you want (to use the fs that you assigned). Outside that function fs is still fs.

const is really just a readonly. It would prevent you from accidentally overwriting fs if you were to forget to type var at some point.

More needs to be written about when to use const, because there isn't much explanation for it out there. It seems like engines can better optimize some code if it knows certain variables won't be reassigned. But in that case you mind up _always_ using const, which I doubt is correct either. There has to be some overhead to using const, so you probably wouldn't want to use it in a tight loop, for example. Or maybe I'm all wrong about this. Need some writing.

<comment><USER19> My example, was perhaps too simple seeing how the functions are very short... I'm sure someone will mention making long functions is a bad idea... but it happens... using const for required modules seems like a simple rule to follow for avoiding trouble... Also, stylistically using an uppercase lettering while not normal in node.js community is normal to JS in other contexts... jQuery... getElementById.. perhaps Fs if you prefer however looking through mozilla code as a guideline - variables declared const are uppercase... hence FS makes better sense to me... because why would a module variable name ever not be... and in the rare case that it is.. declare it var at least until let is available...</comment></comment></comment>


Pencil Project - Sketching and Prototyping with Firefox 3 - <AUTHOR> http://www.evolus.vn/Pencil/Home.html

<comment><USER2> firefox 3. nothing gets put down on the black page. no buttons or text areas, must be something in configuration. possibly web developer extension or adblock. any ideas?

thanks

\</comment><comment></comment><comment></comment><comment>

never mind. i see now that you have to drag the object from the panel on the the canvas and then resizing it. as opposed to selecting it and then dragging the selector rectangle on the canvas..

</comment><comment><USER3> it would be good if it allowed us to draw on the current page we have open as well.</comment>


Prevent NSA from reading our data - <AUTHOR> https://privatemachines.com/enforcer <comment><AUTHOR> seems like a step in the right direction ...

<comment><USER2> Seems like an ad...</comment></comment>


NYC BigApps Competition – $20k In Prize Money - <AUTHOR> http://flowingdata.com/2009/10/06/nyc-bigapps-competition-20k-in-prize-money/

<comment><USER2> it is $5000.00 for the grand prize winner. with the heading I thought 20,000.00 for the grand prize winner. If some body can discuss if one of the applications is picked out as the grand winner, how that person can make money from this. $5000.00 and dinner with mayor seems to be less with the effort you put in. Can that application can be sold to NYC per user or per CPU/Server basis.

<comment><USER3> I'm guessing the most you can hope for is a bit of publicity and perhaps getting on the radar of a couple of NYC tech players. I don't think you lose any IP rights so you can always continue to develop your idea if there is some level of success.

<comment><USER2> Thats what I was thinking. Most probably I am going to go this approach. Use the datasets and refine my program. I was always looking for real datasets. My Program can process all the 170 datasets together without any problem. I looked at some of the datasets, they are not all huge. I am not going to publish my program but approach the VC's directly to showcase my application. With so much effort I don't want to give my program for free. I don't know if you can converge publicity into decent funding for your startup.</comment></comment></comment>