Writing Parsers Like it is 2017 [pdf] - <AUTHOR> http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf <comment><USER2> This should be titled more honestly: perhaps something like "Case studies in rapidly replacing dangerous C parser code with Rust using nom".

The examples are interesting and well presented. But the first sections trying to put a veneer of respectability on rust-all-the-things were a bit rough and got my cynic sense tingling.

Yes, you believe Rust will produce better results: don't try to justify that with facts you don't have ("Several languages were tested .." bullshit, unless you show some data. Likewise the assertions about type-safety and no-GC being essential properties). The data you _do_ have (implementations produced and integrated and tested in a paper-like time frame) are valuable, unfortunately they're cheapened/buried under this false veneer.

<comment><USER3> We in fact tested multiple languages. I can even point you to various works done at the ANSSI like [https://github.com/ANSSI- FR/bootcode_parser](https://github.com/ANSSI-FR/bootcode_parser) (python) or [https://github.com/ANSSI-FR/caradoc](https://github.com/ANSSI-FR/caradoc) (OCaml). I tried Haskell for VLC and it was not really suited for it (GC pauses in a synchronized media pipepline, and not meant to be called from C). But this was not a paper about comparing parser implementations.

Type-safety and lack of garbage collection are essential properties, could you tell me why you don't think that's the case?

Giving the reason for our language choice felt useful. Otherwise, it would have really looked like Rust developers steamrolling into projects :)

</comment></comment><comment><USER4> Is it possible to have "parser generators" (not necessarily in the formal sense of the term) that produce recursive descent parsers? Even if mathematically they can't be perfect, could we have "good enough" ones? Nobody uses parser generators because even though P.G.s "work" on the barest level of ingesting source code and spitting an AST, they don't do anything beyond that. For example, trying to get helpful error messages (think: from old GCC to Clang) from a P.G.s output is close So instead everyone writes custom parsers, and that introduces these problems.

Can't we have smarter parser generators that do make debugging nice, but are still formally verified?

<comment><USER5> > trying to get helpful error messages

Menhir is a parser generator that tries to do that: [http://gallium.inria.fr/~fpottier/slides/fpottier-2015-11-ou...](http://gallium.inria.fr/~fpottier/slides/fpottier-2015-11-oups.pdf) (Don't get scared by the first slide; the title is in French, the rest is in English.)

> formally verified

Menhir has been used for a formally verified parser for C: [http://gallium.inria.fr/~xleroy/publi/validated- parser.pdf](http://gallium.inria.fr/~xleroy/publi/validated-parser.pdf)

The result is in CompCert: [https://github.com/AbsInt/CompCert/tree/master/cparser](https://github.com/AbsInt/CompCert/tree/master/cparser)

</comment></comment><comment><USER6> As long as you're writing parsers, it is forever 1969. Knuth invented all you need to know just recently. Off you go and parse!

</comment><comment><USER7> Nice overview of the pitfalls of C-parsers, their hardening, a presentation of Rust advantages, parser combinators, the nom crate, its usage, the application to VLC and an intrusion detector, the integration with those complex existing C codebase, fuzzing and a few ideas to improve rust for more security.

And I am happy to see the ANSSI here :)

</comment><comment><USER8> No mentions to instaparse? [https://github.com/Engelberg/instaparse](https://github.com/Engelberg/instaparse)

"Parse IS be something easy as regexp"

</comment><comment><USER9> In my experience avoiding unlimited recursion/stackoverflows is one of the most annoying parts of writing a parser, so I find it surprising that the paper doesn't even mention that topic.

<comment><USER10> > In my experience avoiding unlimited recursion/stackoverflows is one of the > most annoying parts of writing a parser

This, x10.

My take is that this is perhaps the main reason why everyone tends to rely on hand-written parsers instead of simply using code churned out by a parser generator. Parser generators are developed with a single use case in mind: pick up a grammar definition, perhaps with pre and post-conditions, and proceed to map it to some programming language. Yet, this fails very basic requirements for real world parser applications.

</comment></comment><comment><USER11> Are there any Context-sensitive algorithms/parsers/generators?

The list at [https://en.wikipedia.org/wiki/Context- sensitive_grammar](https://en.wikipedia.org/wiki/Context-sensitive_grammar) only contains two links, where one of them, "LuZc" seems completely dead with "lorem ipsum" under Downloads, and the other "bnf2xml" seems to be misplaced since BNF is not context-sensitive.

<comment><USER12> Monadic parser combinators are context-sensitive, because you can arbitrarily branch your parser based on previously parsed content.

</comment></comment><comment><USER13> Parser combinators are less powerful than what parser generators can do, in terms of expressiveness and efficiency. And we've known parser generators since the 70s.

So I'm not sure what the point is of the title of the article.

<comment><USER3> (one of the authors here): parser generators are generally good for one thing: parsing programming languages. For more complex formats, where you have to carry state around, or binary formats, they're extremely cumbersome to use. I often meet people that tell me they want the parser generator to end all parsers. But for most real world formats, you'll have to hack around the generator's limitations. Theoretically, parser combinators are less expressive, but they're just functions: you can write whatever you want inside a subparser, and integrate it with the rest. That approach works well, since we wrote a lot of complex parsers with nom.

<comment><USER14> I thought most real world compilers tend to be hand written rather than using a generator? By no means an expert but that's something I've heard and know to be true for many real world compilers.

<comment><USER15> References: [https://stackoverflow.com/questions/6319086/are-gcc-and- clan...](https://stackoverflow.com/questions/6319086/are-gcc-and-clang- parsers-really-handwritten)

<comment><USER13> They probably should have used this instead: [http://scottmcpeak.com/elkhound/](http://scottmcpeak.com/elkhound/)

</comment></comment></comment></comment></comment><comment><USER16> Sorry for the low effort comment but Clever Cloud is an awesome name

<comment><USER17> Thanks, it's a pretty cool product too. (yeah I work there)</comment></comment>


Short Shelf Life: Do we need link-shortening services like Tr.im and Bit.ly? - <AUTHOR> http://www.slate.com/id/2224860/pagenum/all/#p2

<comment><USER2> No. That was easy.</comment>


Why Babel Matters - <AUTHOR> http://codemix.com/blog/why-babel-matters

<comment><USER2> I use CoffeeScript whenever requirements permit. Recently I've been working on a small side project using ES6 (via iojs) and I have to admit that it's pretty refreshing to see JavaScript take on some modern improvements and it's clear that today's CoffeeScript loses out on critical functionality that ES6 brings to the table.

With that stated, I still overwhelmingly prefer CoffeeScript's syntax to ES6. I'm glad ES6 took some inspiration from CoffeeScript, and Babel is a great way to bridge the future of JavaScript over to client's of the present, but I'll always prefer the CoffeeScript syntax for white-space sensitivity, support for optional semi-colons, optional parenthesis for function calls and optional curly braces for object literals. I don't need those features but I _really_ like them. For me, the real future of JavaScript is a re-imagined CoffeeScript that takes on some refined semantics in order to bring ES6 feature support into the CoffeeScript compiler. Admittedly, that is not a simple undertaking (though I'd imagine the code would be simpler as a whole since it would necessarily trash obsolete features like pseudo-classes etc), but I know I'm not the only person who would love something like this.

I don't know how jashkenas is feeling about ES6, but one day I'll have my ES6Coffee, even if I have to brew it myself.

<comment><USER3> I can answer that ;)

ES6 is groovy. Many features are in the runtime and not the syntax, and just work as-is. As other syntaxful features start to come into existence and then universal implementation in most active browsers, CoffeeScript should begin offering them -- at least the ones that align with the mission statement.

Some will be troublesome because of intentional syntax conflicts, like "for of" and perhaps classes. It'll just take a bit of design work to make things copacetic.

That said, in the long run, the future is going to be JavaScript (if it continues to evolve) and languages that are much more radical than CoffeeScript. For more thoughts on that, see: [https://www.youtube.com/watch?v=DspYurD75Ns&t=36m57s](https://www.youtube.com/watch?v=DspYurD75Ns&t=36m57s)

<comment><USER4> Nice talk. Given how you end the talk, have you looked at Elm? If so, what are your thoughts and do you think it satisfies unifying HTML, CSS and JS? (Putting aside the uphill battle of gaining adoption as a static typed, FRP language)

</comment></comment></comment><comment><USER5> Looks absolutely awesome but I still feel like the biggest barrier to more adoption of Babel and similar tools in the workplace just boils down to those coworkers that know some JavaScript, but come from a different background or are simply too junior/not schooled enough.

They can usually deal with basic jquery / angular and vanilla JS (i.e. without too much 'this', 'bind' or 'prototype'). They will have trouble with the ES6 code and they might have trouble with the ES5 JS produced as output. It's a shame really because a combination of Babel and maybe underscore/lodash for added sugar and features makes JS look SO MUCH more solid and modern a language. I hope this takes up and becomes enough of a powerhouse that the powers and balances start to shift.

<comment><USER6> I'm referencing this all the time, but that's because it's great: you may want to show coworkers this tutorial: [https://github.com/lukehoban/es6features](https://github.com/lukehoban/es6features)

I was intimidated by ES6 in the beginning and knew just basic JS with jQuery and Lodash, but honestly starting out with ES6 is pretty easy and I can say I love writing ES6 now! Webpack ([https://webpack.github.io/](https://webpack.github.io/)) simplifies using Babel, this is a good intro: [https://github.com/petehunt/webpack- howto](https://github.com/petehunt/webpack-howto)

<comment><USER5> Thanks for the links, much appreciated. The point I was making though is that ES6 definitely is another world in terms of complexity for newcomers. Things like variadic functions, generators, async/await, destructuring assignment are extremely nice additions that I'm psyched to see coming to the language, but they do add a certain layer of "real language" gravitas to a language that a lot of people in the workplace were merely using to create "directives" and "controllers" or to "get DOM elements". Javascript is not a toy anymore (hasn't been for years actually, but it's getting "real" now).

In the end though, you're right, everyone will take that step, the complexity is nothing overwhelming and those tools you're sharing will help make way for a great future on server and browser alike.

<comment><USER7> EcmaScript is backwards compatible so you don't need to adopt the entire list of new shiny features at once. You can still continue to develop in your usual ES5 syntax and add a few ES6/7 features as you learn them.

In my case, I started with let/const and arrow functions. Then I added classes and hit a few walls, mainly because I hadn't read/understood much about arrow functions and the context they get bound to. After you start to use those, I think everything comes naturally (e.g. realising that the feature that allows you to import {foo, bar} from 'baz' is the same one that allows you to do var {foo, bar} = baz; Deconstruction is very handy, especially when you pass around big config variables and you only need a few bits from it. Not needing to use a promise library for async code is also great. Mixing up async/await with it is something I hadn't thought of until I read this article.

You slowly begin to adopt language features as you find them useful. It's not an all in or all out situation so I think the barrier to adoption is very, very low.

</comment></comment></comment></comment><comment><USER8> I have to agree. I used Coffeescript on my last few projects, but on this one we're using babel/ES6 and honestly? It's pretty good.

And there's some real benefits to writing in actual Javascript, even if you're still transpiling it for production.

Ultimately, I feel like language choice is something of a bet. And while I _like_ Coffeescript, the future of web development is going to be ES6 and ES7, not Coffeescript. That makes it a lot easier to justify spending time on (writing, learning, etc.).

<comment><USER9> Coffeescript is a dialect for (mostly) people who don't like brackets (also cool but controversial features like null swallowing with ?, implicit function calls, etc.), while babel is a transpiler to take es6 down to es5. Saying one is a substitute for the other is like saying ice-cream mud-cake is a substitute for steak and lobster at a restaurant - if it's Saturday night and or your cheat day, just eat both. That is, pipe the output of your coffeescript into the input of your es6 babel in your build step.

I personally use a ton of emberjs with ember-cli, and ember-cli-coffeescript actually just straight-up ships this build pipeline for you when you decide to use coffee.

P.S.: Sorry if I sound like Marie Antoinette saying "let them eat cake", yes, I realize I am lucky to not have tons of legacy code that prevents me from altering my build step, and that there are thousands of other less-lucky engineers who are stuck with build systems that are essentially unalterable voodoo.

</comment></comment><comment><USER10> Whilst I agree that writing ES6 and transpiling to ES5 is a great idea (purely from a maintenance standpoint), I think the author is dismissing the benefits of typed languages too quickly.

In the real world - where teams of people work on codebases of significant size - TypeScript will absolutely dominate the typeless transpiled Javascript languages.

<comment><AUTHOR> I guess I failed to make this point properly, but Babel already supports static typing - you can use a plugin[0] and/or you can use it with Flow[1].

[0] [https://github.com/codemix/babel-plugin- typecheck](https://github.com/codemix/babel-plugin-typecheck)

[1] [http://flowtype.org/](http://flowtype.org/)

<comment><USER11> Unfortunately, both of those are still very much inferior to TypeScript. I'm waiting for flow to improve enough to actually become usable (still missing basic things like ES6 or really any kind of modules support for type exports, afaik?).

In the meantime, TypeScript works rather well and is looking to add JSX support.

<comment><USER12> TypeScript is great, but you might look again at flow. ES6 features are being added (I'm adding let/const support) and many already exist. Import/export (incl. types) are in, fat arrow syntax, destructuring, shorthand syntax for objects.

I get the most value of Flow through statically typed React component props, which is usable today with both `React.createClass`-style and `React.Component`-style components.

In my experience, Flow will infer much more about "plainly" written JavaScript than TypeScript, which will fall back to `any` unless code is annotated.

A small example, function types are contravariant in the negative position in Flow, but bivariant in TS—much weaker!

TLDR, if you haven't looked at Flow recently, look again!

<comment><USER13> Really like the idea of Flow but doesn't look like IDE support is there yet? This is the killer feature of types in Javascript for me - not sure I'd adopt it until then.

<comment><USER6> There are some packages that provide support for flow in atom editor, like: [https://atom.io/packages/ide-flow](https://atom.io/packages/ide-flow)

I've been testing atom for front-end development in the last few days and it's pretty good, definitely worth checking out (I'm saying this as a vim-lover)

<comment><USER14> Atom with eslint, the react plugin and eslint-babel is just amazing for ES6/7 and React development. It's so much faster than it used to be, it's actually amazing.</comment></comment></comment></comment></comment></comment></comment>


Pot Plants Draining Drought-Ridden California - <AUTHOR> http://www.nbcbayarea.com/news/national-international/266119311.html?_osource=SocialFlowFB_BAYBrand

<comment><USER2> Nobody uses that much water to grow indoor weed. Plenty of grow guides around, if I remember correctly water every 3-5 days depending on if coconut fiber or soil, and pot size, flush daily towards the end of the flowering cycle.

Meanwhile, the average California household was estimated in 2011 to use more than 360 gallons of water per day. [http://blogs.kqed.org/lowdown/2014/01/23/how-much-water- do-c...](http://blogs.kqed.org/lowdown/2014/01/23/how-much-water-do- californians-use-each-day-and-what-does-a-20-reduction-look-like/)

Of course nothing was said about the wine industry, or how California uses 6 billion gallons of water annually to irrigate highway vegetation.</comment>


Welcome HN Refugees. - <AUTHOR> http://techstartu.ps/r/techstartups/comments/nk/welcome_hn_refugees/

<comment><USER2> There is already a Minecraft post on techstartu.ps, so I don't think it is only about tech startups.

I don't think splitting is the answer: <http://www.youtube.com/watch?v=iS-0Az7dgRY>

IMO, HN needs to have different category pages for different topics. That would fix things, I think. There is nothing wrong with the link submission process, etc.- it is just getting high traffic.

</comment><comment><AUTHOR> I love HN, I really do, but I like scoped discussions sometimes and I think it'd be great to have a place where we could focus in on that.</comment>


But Rich People Live Here, So We Can't Be Going Broke - <AUTHOR> https://www.strongtowns.org/journal/2018/9/5/but-rich-people-live-here-so-we-cant-be-going-broke <comment><USER2> The ironic thing here, is that Carmel Indiana debt is so high in large part _because it followed StrongTowns requests_.

StrongTowns is constantly telling everyone "you should densify" and "you should slow down / tear up all of your streets" and "chase growth / YIMBY everything" and "hyper-invest in Downtown, only dense neighborhoods matter, middle-class housing is a worthless drain on all of society" \- [https://www.strongtowns.org/journal/2017/1/10/poor- neighborh...](https://www.strongtowns.org/journal/2017/1/10/poor- neighborhoods-make-the-best-investment)

So Carmel does all of that, tearing out intersections for roundabouts, creating bike lanes and dedicated paths, densifying everything, and more-or- less following exactly what StrongTowns is constantly recommending.

But it turns out actually following the StrongTowns wishlist is _really expensive_ , far more expensive than not doing any of it. Now StrongTowns wants to complain that Carmel has a high debt load. If they think that debt isn't worth it, _they should stop telling cities to do all of this StrongTowns stuff in the first place_.

\---

The blog even complains that Carmel built "a New Urbanist downtown out of thin air", but does not acknowledge that this exists _precisely because StrongTowns demanded it_. StrongTowns _is_ one of many New Urbanist groups making those sorts of demands on cities in the first place.

<comment><USER3> Strong Towns preaches incremental development. Building anything "out of thin air" is basically antithetical that that.

<comment><USER4> Sounds like the no true Scotsman approach to urban planning.

<comment><USER5> Can you tell us how it fits the definition of a No True Scotsman?

<comment><USER6> I'm not him - but it's obviously something close, if not full NTS. Real implementations always differ from ideals, so it's always possible to take a divergence and say it makes the implementation antithetical to the ideal. That's the heart of the fallacy. To counter, you'd have to identify the heart of the Strong Towns idea, the 'spirit', and demonstrate how the implementation violates that spirit.

<comment><USER7> Criticizing a specifically incorrect caricature of the tenets of an organization by pointing out the actual tenets of the organization is about as far from No True Scotsman as I can imagine.

<comment> village-idiot It's actually a strawman, ironically enough.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> funny thing about Georgia, or metro Atlanta that is. We just completed the new Northwest Corridor Express Lanes, 30 miles of elevated reversible toll lanes for a whopping eight hundred and thirty four million dollars.

however with regards to the story, Atlanta has its issues with old and needing of repair infrastructure but mostly this comes about because politicians love to cut a ribbon and money goes to new and expensive projects while maintenance gets deferred. This is very evident in heavy rail metro transit systems across the country where it is estimated that over a hundred billion dollars has been deferred.

however the real bomb coming is the public employee pension funds running out of money, from police to fire to teachers to city employees. Chicago has a time bomb set to go off in just a few years [1] and if we thought infrastructure costs were killer wait till the pensions collapse, here is a hint : worn out sewers and bridges won't sue you. Already more than a few cities and counties have filed bankruptcy because of these costs.

rich neighborhoods want more and more services but when the bill finally comes due it is only then that they realize the true cost of that folly. it easy to live on deferred payment plans until it comes due

[1] [https://chicagocitywire.com/stories/511130434-projection- chi...](https://chicagocitywire.com/stories/511130434-projection-chicago-s- police-pension-fund-will-be-broke-in-2021)

<comment><USER9> OTOH, how to fund pensions properly is a solved problem. A properly managed pension fund will have fully funded (with a high degree of certainty) a pensioners' expected payout by the time he retires, and indeed have fully funded accrued liabilities at every point in his career. It's just a matter of relying on a conservative rate of return with a proven track record. Something like 4-6% per annum, IIRC. We know this because of the 200+ years of commercial and regulatory experience with insurance, especially life insurance. People trust their life insurance and annuity policies will pay out because politicians from 100 years ago bequeathed to us a reliable regulatory framework (forged by multiple crises) that penalizes insurers from being "innovative" with the bottom line. That same discipline can and is used for pensions, just not for public pensions at the state level because state governments are often exempt from regulations controlling private actors.

Do we know how to do the same for infrastructure, especially large infrastructure projects? Infrastructure needs and costs are much more dynamic, which makes it easier to fudge numbers and avoid accountability--now and later.

<comment><USER10> There are many fixes. The employees at a company I used to work for funded their own pension, with company contributions up to some thousands a year per person.

The plan was fully funded, too...meaning that it would never run out of money.

<comment><USER11> The point is that many cities did _not_ fund their pension funds to the levels required.

Further, as cities employees (often unions) negotiated better payments and a lower retirement age - because, it's all later! - the gap got bigger and bigger.

</comment></comment></comment></comment><comment><USER12> The data in the "Lost in Place" report that the first point references seems questionable. I spot-checked a couple municipalities I had firsthand experience with (Boston, San Francisco, and San Jose). The worst "fallen star" census tract was the Boston Harbor Islands, which ostensibly has gone from 9% poverty to 82% poverty over the last 40 years. However, this is largely because most existing private uses for the islands have been discontinued, such that the largest complex on them is a sewage treatment plant on Deer Island and a homeless shelter & public services complex on Long Island. When most of a census tract of 1500 becomes a national park and the only thing left is public housing for the homeless, of course the poverty rate is going up.

Similarly, the only "fallen star" in San Francisco was the area around SFSU. If most of the population in a census tract consists of college students without an income, of course the poverty rate is going up. That isn't actually reflective of poverty as we know it, though, because it just so happens those districts include people who are spending hundreds of thousands for a credential that will hopefully let them earn more in the future, and isn't reflective of their lifetime earning potential.

Makes me wonder how many of the other "fallen star" neighborhoods the report references consists of colleges, prisons, or other social services.

</comment><comment><USER13> "I have all this nice stuff, so obviously I was able to afford it. And because I was able to afford it, it's not a problem that I have it. Nothing to worry about."

Did they just make this up? What proportion of people actually think like this?

I think normally you look at your salary (or bank balance) to see how "rich" you are.

<comment><USER14> I think there are a lot of people like that. I've visited homes of plenty of acquaintances that, based on their jobs, earn less money than me, but live a much more luxurious life - for example, a 2700 square foot 4 bedroom 5 bath home, $5000 viking stove (how do I know it was a $5K stove? They were sure to let me know: "Gosh, $5,000 for this stove and it still burns the eggs!"), BMW car for him, BMW SUV for her, private school for the kids (despite paying a premium to live in a desirable public school district). It's possible that they have some alternate source of income, but still I wonder how they can afford all of that luxury.

I think there are more people that look at the equity in their home to see how rich they are than look in their bank account.

<comment><USER15> Who's really the sucker when they can just keep counting on forever increasing real-estate valuations? Even in the 2008 collapse, banks got bailouts and the market today is just as ridiculous as it was pre-2008.[1] "Too big to fail." The cars, the private school, they're nothing but a couple years of home appreciation with a generous tax writeoff discount. Free money, no work required. Houses in the middle of the desert and homes that have burned to the ground, are worth more than a garage full of Ferraris these days.

Savers are stupidly working hard and socking away meager sums rather than hopping on the housing gravy train.

[1] [https://www.washingtonpost.com/news/politics/wp/2017/06/20/f...](https://www.washingtonpost.com/news/politics/wp/2017/06/20/five- years-ago-trump-made-a-prediction-on-twitter-about-housing-he-nailed-it/)

</comment></comment></comment><comment><USER16> I find it hilarious Carmel, Indiana is featured so heavily in this article without mentioning Roundabouts. I grew up near Carmel, and it was famous for its Roundabouts. They have replaced almost every 4 Way Stop with a roundabout. I believe they have more Roundabouts than any other town in the US. They have gone so far as to replace classic overpass bridges over the two major highways with Cassini Oval shaped Roundabouts.

[http://carmel.in.gov/department- services/engineering/roundab...](http://carmel.in.gov/department- services/engineering/roundabouts)

<comment><USER17> Roundabouts are way better and safer than 4 way stops.

<comment><USER18> Unless you're an American driver. Americans already don't know how to use normal ones in Europe. Then in America they make them wrong, with big yield signs that look like stop signs, unintuitive marking, confusing exits, and giant obstructions to the view that force people to stop at the entry to wait to see if a car is coming, and then refuse to enter if they see one far away.

<comment><USER5> It is not true that those things negate the efficiency and safety of roundabouts over four-way stops. Where did you hear that?

</comment></comment></comment></comment><comment><USER19> "Poor neighborhoods subsidize the affluent; it is a ubiquitous condition of the American development pattern"

I don't really see that as a positive, more as another symptom of the ongoing pillage and exploitation of America's working class.

<comment><USER20> Being familiar with Strong Towns I would say the author agrees with you. In general Strong Towns tries to point out that the older and lower income parts of town typically produce a substantial tax surplus while the newer and higher income parts of town are a substantial tax drain. This is because, while each individual homeowner may pay more in property tax, they live in much less density and newer infrastructure is usually a lot more expensive (due to increased engineering requirements, ie. more pavement, fancy street lights, etc.) -- so there are fewer people paying for much more expensive infrastructure.

This is obviously unjust, and the organization is trying to help bring awareness to the problem to help create a movement for change.

</comment></comment><comment><USER21> Although the article references Carmel and its relationship to Indianapolis, I can't help myself from thinking everything written is analogous to Summerlin and Las Vegas, the city where I currently reside. It's scary to think how many other suburbs and cities across the nation where you could draw similar parallels.

</comment><comment><USER22> tldr:

a) city population density outweighs most other factors at producing overall prosperity.

b) suburban development is a bad roi for public financing

c) therefore, a lot of seemingly affluent areas (think gated communities) are actually going to ruin, because the roi on public financing can't keep them affluent.

the article is interesting, but light on quantitative analysis. you're supposed to accept that the author ran the numbers.

in particular, i doubt that misallocated public financing is the main reason for a city to grow or shrink. the global economy is too strong.

there could even be reverse causation -- all the best urban planners left cleveland as it shrank, which resulted in waste...

<comment><USER23> "...all the best urban planners left cleveland as it shrank, which resulted in waste..."

???

But if they all left Cleveland, wasn't that because the places they moved _to_ were more desirable for whatever reason?

And if those other places were more desirable, doesn't that imply that they missed something in their planning? (Or else they would have done the planning to make their _own_ place that desirable.)

Serious question BTW. I'm not trying to be snarky.

<comment><USER24> > But if they all left Cleveland, wasn't isn't that because the places they > moved to were more desirable for whatever reason?

Yes, for instance, jobs for urban planners, which are both more plentiful and better paying in growing (both population and economy) areas.

> And if those other places were more desirable, doesn't that imply that they > missed something in their planning?

No, in the same way that an investment planner that experiences a known risk that would have been more likely under alternative courses, or who underperforms other portfolios that benefited from access to investments only made selectively available to people who owned particular investments before that advisor came onboard have not necessarily missed anything. Unavoidable risk and opportunities constrained by initial conditions definitely affect urban planning.

</comment></comment></comment><comment><USER25> Detroit has an excuse, it follows the auto industry's fate. Indiana just elects too many republicans.

</comment><comment><USER26> Wow. I lived in west Indiana in the late 90s, remember Carmel as the 'new In place'. Looks like they're headed for trouble.

Bummer. Hope city planners are taking note.

<comment> village-idiot I'd bet that they aren't.

</comment></comment><comment><USER27> Big-screen TVs start from $150 these days so I think they should not be mentioned as splurge wealth anymore.

<comment><USER28> The "brand new car" thing isn't a great example either. You can lease a new car for under $100/month which likely has lower insurance costs, is safer, and no maintenance fees other than gas (which you'll also need less of since its probably a more efficient vehicle).

An older car could end up needing several thousands of dollars in repair costs at any time, and maybe more than once. I drive an older car because I could swing a new engine or transmission if it came up. For a lot of people that means they no longer have a car.

<comment><USER29> > The "brand new car" thing isn't a great example either. You can lease a new > car for under $100/month which likely has lower insurance costs, is safer, > and no maintenance fees other than gas (which you'll also need less of since > its probably a more efficient vehicle).

Few people (like yourself) buy commodities in increments limited by their needs. Most people buy commodities limited only by their total borrowing capacity.

The unofficial Theory of Consumer Spending holds that "where credit is extended, it will inevitably be utilized." It's no coincidence retail chains push their own credit cards. Offered a $300K loan, people will buy a $300K house.

Most consumers are ignorant of terms. If the possibility exists to literally sign a dotted line and drive away in a new Range Rover, few people will opt for your plebeian Accord.

</comment></comment></comment><comment><USER30> 2 things that bother me in this article: misconceptions about the nature of finance, and the role of real-estate brokers

The first one is illustrated in the 'hyperloop affordability' paragraph.

What bothers me here it the confusion about the nature of fiat currency. In fiat currency based financial system, money is not realy a resource in the true sense. You don't need 'work' (in the energy sense) to create it. One push off a button can create limitless amounts of it. Money is 'merely' a means of prioritization.

This is a subtle but essential difference. You can 'afford' something if you have the knowledge and the free (prioritized) energy (work) to invest in (choose to do) it. In classic balanced systems, where money and 'potential work energy' are in balance, the difference is small. In our real world financial system, where this is nowhere near close, both are very different.

The second thing that bothers me is the lack of highlighting the active role of real estate brokers and speculators on the dynamics of rising and falling 'neighborhoods'.

These businesses live of fractional transaction fees. Some real-estate is highly profitable as it generates a lot of transactions. A good-looking but 'bad' house where people often find out it is not so nice to live there and move on asap is a start in the realtor market. It generates potential transaction fees on the sale every few years.

By contrast, a truly good home is sold on the market maybe once every 2 or 3 generations if ever. The only way to 'unlock' these houses is to take away their 'goodness'. Small things can be leveraged into high market dynamics.

Typical things are lobbying local authorities to divert go-through traffic. Once peaceful and nice neighborhoods now become polluted and noisy, often resulting in a mass exodus by those that can afford it. Previous traffic hellholes that could be bought up for pennies suddenly become nice, relaxed and very desirable. A decade or 2-3 later you reverse the process and hit the jackpot again.

Another trick is to buy a house on a nice street, and rent it out to a toxic person/family and let the butterfly effect do it's work.

Not nice, but unfortunately very effective

<comment><USER31> The point about transaction fees sound tru-ish...but do you have any evidence to support any of the above?</comment></comment>


Amazon created the expectation of 2-day shipping. Now it needs to scale back - <AUTHOR> https://www.vox.com/the-goods/2019/4/23/18508093/amazon-prime-two-day-shipping <comment><USER2> Every time Amazon threads pop up, there are always complaints about delivery.

Maybe it's because I live in the greater Seattle area, but in my 10+ years of having Prime, I can only count a handful of times where my shipment arrived late, and I've always been refunded a month of prime from CS.

</comment><comment><USER3> Just as a note that market I am in seems to have lots more free ONE day delivery. I don't even get why they advertise that - you used to be able to pay $3.99 or something for one day, now its free? And also in an amazon now delivery zone which goes even faster.

Amazon just did a deal for something like another 20 Boeing 767's. I'm very surprised to hear they are pulling back from 2 day / prime. My experience is they are going the other way.

<comment><USER4> I wonder if they're trying to do something like drive traffic to certain products which they can ensure they have in abundance? That way they don't have to ship your favorite color flash drive halfway across the country overnight, they can just ship a pallet of them to your city and suggest you buy that one instead.

</comment></comment><comment><USER5> This article is a joke. They are the only company reporting on something, without providing any evidence of them publicly stating that they are pulling back their prime delivery initiative, especially when in their quarterly earnings they state this :

> January 31, 2019 at 4:01 PM EST Amazon Air launched a new gateway operation, > in Riverside, CA and announced three additional gateway operations that will > launch in 2019: Wilmington, OH; Alliance, TX; and Rockford, IL. Amazon Air > provides gateway operations – onsite airport facilities to load, unload, and > sort packages – at over 20 airports, making two-day shipping possible almost > anywhere in the U.S." [2]

Do not waste your time.

Did amazon publicly state that they are moving away from 2-day shipping?

The only thing I can find is information related to their Amazon Day. [1]

[1]([https://www.amazon.com/b?ie=UTF8&node=17928921011](https://www.amazon.com/b?ie=UTF8&node=17928921011)) [2]([https://ir.aboutamazon.com/news-releases/news-release- detail...](https://ir.aboutamazon.com/news-releases/news-release- details/amazoncom-announces-fourth-quarter-sales-20-724-billion))

<comment><USER6> It certainly _feels_ like I've had more Prime orders not show up in 2 days, when viewing the last 6 months, vs. those before that.

As a household we do about 400 orders a year on Amazon with a couple spikes around e.g. Christmas, but a consistent baseline of at least 20-25 monthly.

There's a CSV you can pull which shows all the orders you've ever made, on what date, the cost, etc. I can't recall if it logs a date for when it was delivered. Will have to look later.

<comment><USER5> Not sure if you saw this, but :

[https://qz.com/1605167/amazon-to-make-free-one-day- shipping-...](https://qz.com/1605167/amazon-to-make-free-one-day-shipping- standard-on-prime/)</comment></comment></comment>


Kaggle contest aims to boost Wikipedia editors  - <AUTHOR> http://www.newscientist.com/blogs/onepercent/2011/07/kaggle-competition-aims-to-giv.html

<comment><USER2> I'll quote myself from [http://blog.wikimedia.org/2011/06/28/data-competition- announ...](http://blog.wikimedia.org/2011/06/28/data-competition-announcing- the-wikipedia-participation-challenge/) about the competition:

Reading more, I'm pretty troubled by the selection of data: [http://www.kaggle.com/c/wikichallenge/forums/t/674/sampling-...](http://www.kaggle.com/c/wikichallenge/forums/t/674/sampling- approach)

What's the point of predicting only about recent editors, whose ranks have already been thoroughly harrowed by the endless tightening of policy and rise of deletionists? Wikipedia already has a horrendous reputation for screwing over contributors _, so anyone who does much editing (and whose departure would be noticed by the criterion) is self-selecting now.

_ just the other day cryonics researcher Mike Darwin told me he had no interest in contributing because he was sure all his contributions would be reverted under an extremely narrow reading of WP:RS, and wondered whether his BLP article could just be deleted since he certainly wasn't going to edit it into an article worth a damn

</comment><comment><USER3> Despite the flippant title, this seems like a very good idea.

I believe that positive feedback of this kind is the sort of thing that allows wonderful sites such as stackoverflow to exist.

The competition itself seems accessory, though. The real interesting bit is that Wikipedia is essentially adding its own "like" or "+1" button. I hope it keeps the term "love" button, even if it does seem out of place (at first!) for stuffy old Wikipedia.

Now that I think about it, maybe this will begin a push to have Wikipedia seen as less of a stuffy old place filled with angry pedants and more of a "community garden" of knowledge. Not that I'm advocating less editorial integrity, its just that Wikipedia really needs more measures to lessen the perceived hostility (once you get inside the place), so this seems like a little start towards that end and a big plus to me.</comment>


The Ultimate Playlist for Startup Founders - <AUTHOR> https://medium.com/play-startups/the-ultimate-playlist-for-startup-founders-part-1-d6adcb100a7e <comment><USER2> I thought this is just a lame music playlist. This is even better!</comment>


Show HN: Browser, WS, Excel and PDF Automation with JavaScript - <AUTHOR> https://42elements.com/automation-suite/features

<comment><AUTHOR> Hello HN!

I just uploaded our first website. So... what do you think about it?

For scripting samples, you can have a look at [https://42elements.com/automation-suite/scripting- examples](https://42elements.com/automation-suite/scripting-examples).

Thanks, Phil</comment>


Amazon Not as Unstoppable as It May Appear - <AUTHOR> http://www.nytimes.com/2014/12/18/technology/personaltech/amazon-not-as-unstoppable-as-it-may-appear.html

<comment><USER2> If you look at where Amazon decided to build it's headquarters (South Lake Union in Seattle), and how it decided to significantly expand it, you'll see how much of a gamble they are making as a company. South Lake Union was never meant to be a tech sector (historically it has been a center for biomedical research, but the influx of computing solutions has challenged the need of space in biomed research labs) - and is known for grid lock and poor traffic patterns. But Amazon is going full forward: they are building more cafeterias, more offices, more parking.

It is my opinion that Amazon will live or die by this decision. Seattle is the fastest growing (per capita) city in the United States and already has had (for decades) a housing, traffic and parking problem. The plans that Seattle has to expand public transportation do not include plans which will help the chokehold situation in SLU.

Currently Amazon only works because: the cost of housing versus the income from Amazon is balanced with the insane hours they demand of their employees and the traffic that is only helped by the odd hours that employees end up working. As the price of housing increases, especially in those areas with easy access to Amazon HQ, and as the traffic situation becomes worse, and as Amazon burns out both its reputation and potential long term employees, the long term prospects of Amazon's HQ IMHO are not very good. The more employees are squeezed and the less they are compensated, the more the pressure to work must come not from compensation but from political pressure - but I think other opportunities in the area will drastically outperform Amazon in terms of compensation and work-life balance in this world, so I expect Amazon to falter.

</comment><comment><USER3> The article may apply to heavily urban areas, but in more rural areas, Amazon is the only game in town besides getting in the car and heading to the local Wal-Mart. I can't see most of these localized delivery services getting national traction simply because it doesn't make economic sense in rural/suburban areas, the population density isn't high enough.

<comment><USER4> More than that, I've never had a bad experience with Amazon. I'm not saying they don't happen, I'm saying I personally have _never_ , in all the years I've been using Amazon, had a bad experience.

I have nothing but praise for Amazon and as time goes on I find myself more and more simply ordering things from Amazon even if they're available locally.

</comment></comment><comment><USER5> It's worth pointing out that many of these startup "threats" use AWS, including Postmates ([https://angel.co/postmates/jobs/44964-software-engineer- infr...](https://angel.co/postmates/jobs/44964-software-engineer- infrastructure)).

</comment><comment><USER6> I don't think anybody can predict Amazon's future. There still isn't enough competition. Once another brand can be recognized as equally trustworthy as Amazon is, maybe there will be a chance for it's demise. However, the Fire Phone fail will definitely not expedite that potential process</comment>


Syntactic sugar in C – (ab)using "for" loops - <AUTHOR> http://zserge.com/blog/c-for-loop-tricks.html <comment><USER2> I will never understand why these examples are considered abuse as they exhibit standard behavior.

It's just as if I were to write the following JavaScript:

      node.classList[ isHidden ? 'add' : 'remove' ]( 'hide' );

I'm simply using a ternary and a bit of reflection, but the arguments regarding "correctness" this engenders...

<comment><USER3> Can you explain a bit further what the code you posted does?

<comment><USER2> Element.classList:

[https://developer.mozilla.org/en- US/docs/Web/API/Element/cla...](https://developer.mozilla.org/en- US/docs/Web/API/Element/classList)

Property Accessors (Bracket Notation):

[https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Operators/Property_Accessors#Bracket_notation)

Conditional (ternary) Operator:

[https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Operators/Conditional_Operator)</comment></comment></comment>


Kubernetes 1.6: Multi-user, Multi-workloads at Scale - <AUTHOR> http://blog.kubernetes.io/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale.html <comment><USER2> Those who have used kubernetes so far, what is your opinion on the kubernetes ecosystem? Is this the holy grail? Is there anything missing that you would like to have?

I have found kubernetes hard to learn. There are a lot of concepts. That in itself isn't bad, but I have found that the quality of the documentation is variable. Once I get past the basics tutorial, I have the feeling that I have landed in a big information dump that require expert knowledge ala the git man pages.

<comment><USER3> Yeah, I feel you. I found kubernetes very hard to learn as well. I wanted was to find a good tool to run a SaaS (to handle 10k users). Only after reading up a lot did I even realize that this was not for me. I had fallen into the Hackernews hype trap and thought kubernetes is the right tool for me. I am back to my simple docker based deploys in 5 EC2 instances. It's very much by hand but works with some simple instructions to follow on a wiki page.

I have also found kubernetes labor hard to find. The ones I found were way too expensive for me (upwards of 150k USD).

<comment><USER4> Checkout Distelli ([https://www.distelli.com](https://www.distelli.com)). UI and pipelines that make using Kubernetes easier. Tons of features coming soon.

I can also help you with Docker / Kubernetes even if you decide not to buy anything from us - happy to help. Email is in my profile.

Disclaimer: I'm the founder at Distelli.

<comment> stephane-klein I think that Distelli is like Build in OpenShift ([https://docs.openshift.org/latest/architecture/core_concepts...](https://docs.openshift.org/latest/architecture/core_concepts/builds_and_image_streams.html#builds)), isn't it ?

</comment></comment></comment></comment><comment><USER5> I couldn't find it easily, but is CronJob out of alpha? As always, great work. I have no regrets about choosing k8s.

<comment><USER6> No it hasn't. You can track the progress of CronJob by subscribing to the feature issue (which should generate fairly low email traffic):

[https://github.com/kubernetes/features/issues/19](https://github.com/kubernetes/features/issues/19)

<comment><USER5> Thanks.

</comment></comment></comment><comment><USER7> One thing that's still missing but would be quite valuable is a good egress approach/configuration. For example, we use an external PostgreSQL provider in which I can configure access IPs. Since K8s nodes (on GKE) get different IPs, I have to be very loose with CIDR selection, which I don't like.

<comment><USER8> Wouldn't The Right Way (TM) be to have a daemon running on the cluster that's watching either your nodes (if you want to allow access from all your nodes) or specific pods and then call your PostgreSQL provider's API to let it know about valid access IPs dynamically?

<comment><USER9> That's the approach we used when connecting to a legacy Mongo cluster from a GKE cluster. We ran a pod that subscribed to the Kubernetes api, and updated security group rules in AWS as the nodes changed.

</comment></comment></comment><comment><USER10> To author: custom metrics link is broken.

Looking forward to compare that with an autoscale solution I'm working on.</comment>