Can the Appalachian Trail Survive 'A Walk in the Woods?' - <AUTHOR> http://www.outsideonline.com/2011851/can-appalachian-trail-survive-walk-woods <comment><USER2> The generational shift isn't between people, but between decades. Many of the "leave no trace" hikers today were very different in their youth. Look through the history and you will find people in the 60s regularly doing things that today are simply not allowed (fires, cutting down small trees etc). So it isn't that people are different today. There are just more of them on trails.

Some would say the answer is to provide more services such as better camping accommodations and harder trail surfaces to handle the extra people. I do not support this. I suggest that making trails easier attracts more people, only exacerbating the problem. It's a game that cannot be won.

So rather than try to accommodate all these people, perhaps parts of the trail should be made less accommodating. Rock climbers do this all the time. See debates over sport (heavily bolted) v. traditional climbing methods. Adding safety features to a route attracts more traffic. Making/keeping a route difficult or even dangerous keeps beginners away, which reduces traffic. If we assume that there will always be more people in the future than there are now, that if nothing changes population pressure will always increase, then actively trying to keep people away may be the only sustainable plan.

<comment><USER3> > So rather than try to accommodate all these people, perhaps parts of the > trail should be made less accommodating. Rock climbers do this all the time.

This makes perfect sense if the goal of being a hiker is to show that you're more macho, or otherwise more morally worthy, than non-hikers.

It makes no sense at all if your viewpoint is that nature is beautiful and people should be encouraged to experience that.

<comment><USER2> But allowing so many people to enjoy that beauty simultaneously works to destroy that beauty. So to protect you must either you take steps to dissuade people, or resort to some form of enforced quota system. When it comes to public resources I'd rather see dissuasion than quotas.

If machismo works to reduce the footfall on a trail, so be it. That's much better than a gated trailhead manned by a guard taking tickets. And its far better than paved sidewalks and concrete staircases replacing trails.

<comment><USER3> > to protect you must either you take steps to dissuade people, or resort to > some form of enforced quota system

This isn't true. You can channel people into the behaviors you want by making them easier; it's not an all-or-nothing "no matter what our environment is like, 3% of visitors will leave litter" situation. There are many things you could do to reduce environmental damage while accommodating _more_ visitors:

\- You could put handrails around the trails. People aren't supposed to leave them anyway.

\- You could station trash cans along the trails. This makes it much easier to throw your trash in an appropriate place.

\- You could establish fire pits in which it was officially OK to have fires.

\- You could patrol the trails. This doesn't work well when hikers are rare, but it scales beautifully as they get more common. Or, you could have a stationary security presence in problem areas.

\- You could blaze new trails.

Everything I've listed except trail patrols is something I've personally seen in some areas. (Full disclosure, I'm actually just assuming that new trails get blazed from time to time. I have, however, personally experienced trails being radically reworked between visits.)

> [machismo is] far better than paved sidewalks and concrete staircases > replacing trails

Why?

<comment> jack-r-abbit Handrails don't keep off-trail hikers from hiking off trail. Trail etiquette keeps people on trail. Respect to nature keeps people on trail.

Garbage cans in the middle of nowhere still need to be emptied or else they become full and no longer serve the need. A lot of these places are remote. It might take several hours to empty one trash can. Our parks barely have enough resources to maintain as they are. We shouldn't need to pay someone to hike in and remove your trash. I don't think it is too much to ask that if you hiked in with 5 full snickers bars that you hike out with their wrappers. Your pack always gets lighter as you go so there really is no excuse for not coming out with all your trash.

<comment><USER4> I heard "Always carry out more than you brought in," and try to go with that in mind when I can manage a good hike.

</comment></comment></comment></comment></comment></comment><comment><USER5> I REALLY want to explain this away as the complaining from some grumpy park rangers. Then you have these stories and you begin to wonder if there is something generational going on.

Prom Date spray painted on Black Rocks -[http://jonathanturley.org/2015/05/08/destinys-child- police-s...](http://jonathanturley.org/2015/05/08/destinys-child-police- search-for-teenager-who-defaced-park-cliff-to-snag-a-date-to-the-prom/)

Casey Nocket - [http://www.stgeorgeutah.com/news/archive/2014/11/08/ams- woma...](http://www.stgeorgeutah.com/news/archive/2014/11/08/ams-woman-paints- faces-defacing-8-national-parks-including-zion-canyonlands/#.VenrqBHBzRY)

<comment><USER6> Why jump to a generational explanation?

It could just as easily be a function of population growth, easier access (e.g. more info available about how to get outdoors), better marketing by the NPS to attract more visitors, etc. More people visited the parks last year than ever before.

<comment><USER5> Because in both cases I linked to, the perpetrators were under the age of 25.

Sure it's anecdotal ... but you did ask.

<comment><USER7> But wouldn't you expect most vandalism in general is done by people around 25 and younger?

I would expect most of the mining company executives organizing whole mountaintop removal are well over 25, since most executives are over that age. Goes a little beyond graffiti.

<comment><USER8> He would, yes. _That 's the point._

<comment><USER7> To say it is a generational thing doesn't mean it is always the current young generation, it means it is specific generation(s), i.e. generation X, millenials, etc.

</comment></comment></comment></comment></comment></comment><comment><USER9> I don't think this is as much of an issue as being portrayed. I've hiked 2 sections of the AT this summer and found no trash in either of them. I could see certain parts like the beginning and ending being worse, which would be expected. Designated camping spots weren't overcrowded. Besides cheeky motivational sayings written over trail markers, everything in both sections were pristine.

</comment><comment><USER10> Not a fan of either film but I really enjoyed both books. I think Wild has substantially further reach, especially among women, while Bryson's book is amusing and entertaining, yet ultimately forgettable. Either way, an increase in Americans focused on exercise, spending time in the wilderness, and general soul-searching activities will be a good thing.

<comment><USER11> > Either way, an increase in Americans focused on exercise, spending time in > the wilderness, and general soul-searching activities will be a good thing.

I disagree. The problem pointed out in the article is that a lot of people aren't there to exercise and soul search, and they're ruining it for people who would like to do so in the future by trashing the place.

It's absolutely _not_ a good thing if many of the people are going into the wilderness and destroying it with trash, vandalism, and dog shit.

<comment><USER10> > dog shit

You know the woods are filled with animals that shit in the woods all the time, right? People should be burying it or at least moving it off trail but feces is a purely natural occurrence.

The trash and vandalism I absolutely agree with you.

<comment><USER12> The reason you aren't allowed to have dogs on Katahdin is because that type of animal doesn't actually go up into the alpine zone of Katahdin. The plants there are extremely sensitive and cannot survive being stepped on by animals. And they are only able to grow for a couple weeks a year, so one dog can kill decades of growth by stepping on a small plant.

So, I agree with the woods part, bring all the dogs you want onto the trail when you're in the woods, but when the rangers in Baxter State Park complain about people bringing dogs up the mountain, they are absolutely in the right.

</comment></comment></comment></comment><comment><USER13> "Baxter officials say thru-hikers are openly using drugs and drinking alcohol, camping where they aren't supposed to, and trying to pass their pets off as service dogs." \- Sounds like a pretty good time to me.

I don't think that I can get behind a complaint that people are hiking in the wilderness _too much_. This is a good problem to have.

<comment><USER14> These are the kinds of folks on the AT: [https://www.youtube.com/watch?v=gjyNO0Ltc6U](https://www.youtube.com/watch?v=gjyNO0Ltc6U). They're partiers, not hikers, who are destroying the wilderness and opportunities for solitude.

<comment><USER15> I'm confused how people can party every night and then hike. The problem is the AT is just so accessible these are the things you're going to find when something becomes hip.

Head to the Rockies or out to Oregon if you want solitude hiking. When I hiked Mt. Bierdstadt in CO I was completely alone for 7 hours and never saw another person the entire day.

<comment><USER16> I attempted a thru hike in 2005. The thing about hiking is, doing it is a lot more difficult than talking about it. Something like 60% of thru hikers give up in the first 20 miles of their 2100 mile hike.

That being said, of course there are people like in this article, but they're only at the shelters that are close to town. Walk a bit away from the town, and you're golden.

Walking 15 miles into the woods to "party" is a huge ask. Shitty people are lazy.

The real story behind all of this is how young / homeless / disenfranchised people are turning to the trail as an outlet / support group. That is more interesting to me, and worthy of a story, rather than judgement as doom of the trail.

<comment><USER17> That 60% statistic is incredible. It takes months of planning and preparation to thruhike the AT. Throwing it all away on the second day is mind boggling to me.

<comment><USER15> I don't think many of the people you see in videos or in this article are doing months of planning. They buy a pack, quit their job and show up.

</comment></comment></comment></comment></comment></comment><comment><USER18> The biggest problem I see today is that there are so many hikers who say "leave no trace" and then kind of just treat the outdoors like their bedroom.

You can't do anything about the boat campers and the cooler campers, but the backpackers and hikers that I have been around have been less conservation minded than I would like.

<comment><USER8> In my experience, backpackers are the _least_ inclined to bring their trash back out with them. Too many selfishly prioritize their comfort (particularly, how much weight they are carrying) over respect for the environment.

<comment><USER19> Really? Where? I've done several multi day backcountry backpacking trips in national parks recent years, and I can't think of a single piece of trash I've seen or person I've seen leaving trash at camp.

</comment></comment></comment><comment><USER20> Gary Player had an epic rant[1] about public golf courses getting harder and its affect on amateur numbers. I point to that example to explain my worry about making the trails more inaccessible to cut down the traffic. Making the normal person see the trail as a plaything for the elitist will not help future funding.

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

</comment><comment><USER21> Here's the ALDHA's newsletter from this past winter which gives a more detailed account of the problems at Katahdin. [http://aldha.org/newsletter/2014D_winter.pdf](http://aldha.org/newsletter/2014D_winter.pdf)

I thru-hiked in 2007, and many of the problems now were in their infancy but not out of hand yet. There has always been a couple bad apples, but this is simply a result of the numbers.

In June, I was visiting family near the trail at the same time the wave of thru-hikers comes by, and I couldn't believe how many there were. I also gave two thru-hikers a hitch, so I had a chance to talk to them about some of this. They estimated about 4x as many hikers compared to the year I thru-hiked. And I think they said there was one campsite somewhere down south with 89 tents (or hikers I can't remember) in a single night. One of them said they were hiking this year specifically because they heard the movie was coming out.

</comment><comment><USER22> Fundamentally, the Earth is finite and people are growing geometrically. If we're not at the 'natural spaces and trails' load limit now, we will get there sometime soon.

Rationing is a frustrating solution. It means, only the special few get to enjoy these spaces. Then it no longer 'belongs to all of us' i.e. isn't a public space any more. So should the Federal Govt even administer it? Why do we all pay for it, when only a special few get to go there?

I'm not anti-conservation. But these questions inevitably will arise as population (& demand) grows and the public spaces stay exactly the same size.

<comment><USER23> What makes you think we are near the limit? There are two major north-south trails in the U.S. and the PCT is not crowded. It seems totally reasonable to increase the number of such routes by 10x or 100x. There is a lot of open space, and backcountry trails and camps are not particularly disruptive.

<comment><USER22> Population grows geometrically. Land area is a constant. QED

</comment></comment></comment><comment><USER24> I hate to see a quota imposed, but if the problems increase (who takes a hairdryer into the wilderness??) maybe there needs to be some qualification hikes, much like how you have to finish a certain number of marathons before being allowed into the Boston marathon.

<comment><USER25> You only have to finish 1 marathon before running Boston, you just have to run it fast enough to qualify. [http://www.baa.org/races/boston- marathon/participant-informa...](http://www.baa.org/races/boston- marathon/participant-information/qualifying/qualifying-standards.aspx) You can also get in with a charity slot without qualifying.

</comment></comment><comment><USER26> Was it even a good movie? I've heard pretty negative things about. I'm a fan of long distance walks but I've been reluctant to see the movie thus far.

<comment><USER27> The movie _Wild_ is a good film. It might not be good if you know anything about long distance walking and wilderness trails. In the same way that movies get coding and cracking wrong, even if they make an attempt at honesty.

<comment><USER26> Yeah _Wild_ seemed like a good film but I didn't like how much they got wrong. I'll check out _Do More With Less_ per the other poster's suggestion.

</comment></comment></comment><comment><USER28> Maybe coming soon: a toll gate. Onstensibly to pay for trash pickup. Really to pay for a park official mid-management bureaucrat's pension.</comment>


IOS Nib helper for 3.5 and 4 inches  - <AUTHOR> https://github.com/kirualex/KANibHelper

<comment><USER2> Nice. You should change the naming convention to match with the iPad default nib naming convention (~ipad nib names will auto load on iPads).

What I do is:

iPhone 3.5 = nibName~iphone3_5

iPhone 4 inch = nibName~iphone4

iPad = nibName~ipad

Then, when I'm editing my nib files in Xcode, it's much quicker to figure out which one to click on based upon the name.

<comment><AUTHOR> good idea, I'm gonna build upon that !</comment></comment>


A Transparent Solar Cell That Makes Every Window a Power Source - <AUTHOR> http://www.offgridquest.com/extra/a-fully-transparent-solar-cell-that-coul <comment><USER2> As said in comments, it's a "repost" from years ago. 2015 news about the company : [http://www.businesswire.com/news/home/20150528005832/en/Ubiq...](http://www.businesswire.com/news/home/20150528005832/en/Ubiquitous- Energy-Demo-World%E2%80%99s-Transparent-Solar-Technology#.VhstY3Vq1xA)</comment>


I think string theories are wrong - <AUTHOR> http://www.huffingtonpost.com/benjamin-t-solomon/strings-are-dead_b_7560444.html <comment><USER2> Oh boy. I also think that string theories (in their current state) are wrong and possibly a dead end, but I feel uneasy reading this. Besides the harmless typos [0] in the article and his questionable academic affiliation (iSETI [1], which does not pass the straight face test), his referenced publication [2] is published in a questionable journal [3] and begins with an abstract that jumps around from topic to topic while "introducing" new terminology such as "kenos" and tau, a "change in time dilation over a specific height."

[0] E.g., "Noble Prize"

[1] [http://www.iseti.us/](http://www.iseti.us/)

[2] [http://www.scirp.org/Journal/PaperInformation.aspx?PaperID=3...](http://www.scirp.org/Journal/PaperInformation.aspx?PaperID=36276)

[3] [https://en.wikipedia.org/wiki/Scientific_Research_Publishing](https://en.wikipedia.org/wiki/Scientific_Research_Publishing)

<comment><USER3> (the "straight face test" I wonder to myself, the author claims some endorsement from t'Hooft, maybe some eccentricity can be tolerated...)

Just following the link is enough to tell that indeed, under any reasonable definition of "straight face test" that site would not pass as an academic affiliation. I suspect that the "endorsement" from t'Hoof was more of the "I don't care, send it to these guy" followed by a brisk walk in the opposite direction.

As to the issue at hand, I don't think anyone claims to have a complete string theory to begin with so it's not really an issue of proving anyone wrong.

The sad truth is rather that despite lots of work by many people, string theory and/or supersymmetry, these ideas from a past millennia, are basically the frameworks which produces most somewhat novel ideas today. And its not like people don't try other things, the criticism that string theory is a dead end is at least twenty years old by now, so it's not like there are no incentives to come up with new stuff.

It is true that for a while there was an awful lot of papers with strings or string like words going up on the archive, but looking at the actual production right now, hep-th seems to be into black hole information paradox. So maybe Smolin and Woit making all that fuss did have an effect. Or maybe the graduate students thinking of going into string theory found Luboš blog and decided that accounting was probably more fun anyway.

<comment><USER4> > are basically the frameworks

This is precisely it. The name "String theory" is a bit of a misnomer; it's a framework, not a scientific theory like evolution or special relativity despite the common perception. Sure, it does make predictions (like tiny bits a vibrating energy or "strings" are the most fundamental thing in the universe), but that's a lot like playing solitaire in windows and then proclaiming it a bad OS. Strings are only a tiny piece of a much larger framework.

String theory is a framework in which you build scientific theories. Where relativity or evolution might be programs on a computer, string theory is the OS. Which is why there's so much confusion.

And to say it's a dead end is incorrect; to date there have been some incredibly useful applications in unrelated fields. People are using it for all kinds of things. Even if it's not a theory of everything, it is still helping advance our knowledge and understanding of science.

</comment></comment></comment><comment><USER5> So to precis the intro: "I was asked by a Nobel laureate to submit this to peer review, but I thought it would take too long, so I self published".

Yeah, the Nobel laureate told you that, not as an endorsement, but because it is the standard response. "Ah yes, that is... erm... interesting... how about you submit it for a notable journal. Oh sorry, I need to go talk to whatshername over there, kthnxbai."

Peer review exists for a reason. Specifically, the merits of theories can't be assessed via HuffPo opinion pieces, and the ratio of rubbish to quality speculation is so large, that actual professional scientists need a filtering mechanism.

</comment><comment><USER6> "In 2013, I presented the paper "Empirical Evidence Suggest A Need For A Different Gravitational Theory," at the American Physical Society's April conference held in Denver, CO. There I met some young physicists and asked them about working on gravity modification. One of them summarized it very well, "Do you want me to commit career suicide?""

"What worries me is that it takes about 70 to 100 years for a theory to evolve into commercially viable consumer products. Laser are good examples. So, if we are tying up our brightest scientific minds with theories that cannot lead to empirical validations, can we be the primary technological superpower a 100 years from now?"

...

I get the feeling that proposing something bold and wrong in physics results in a 'crackpot' label, effectively ending your career. So if you want a career, stay away from making bold predictions. Stay away from _testable_ new ideas!

Perhaps the attraction of string theory is that it never leads to testable specific -- and therefore possibly wrong -- predictions. There are infinitely many permutations of string theory, all of which are mathematically potentially valid. So you can publish forever on string theory and never be wrong.

Reminds me of the old Star Trek TNG episode where they killed the Borg collective by giving it an impossible but mathematically valid shape to contemplate. It contemplated, and contemplated, and contemplated, and... stopped doing anything else. Since the halting problem is unresolvable, it's possible to contemplate within the bounds of any Turing-complete mathematical system forever.

<comment><USER7> Lasers are terrible examples, they were invented in the 60s and an absolute upper bound on their introduction into the consumer market is 1982.

<comment><USER8> They stand on theory that started to come together ~1900.

<comment><USER9> To be more specific:

> Albert Einstein first broached the possibility of stimulated emission in a > 1917 paper

[http://www.aps.org/publications/apsnews/200508/history.cfm](http://www.aps.org/publications/apsnews/200508/history.cfm)

<comment><USER10> You need more than stimulated emission for a laser. I think that figuring out how to create a population inversion in an excited state is the best candidate for the inception point of the laser as a specific possibility, and I believe the honor for that achievement goes to Townes circa 1950.

<comment><USER9> Nothing is ever simple. Before Townes' 1951 population inversion, there's also Kastler's 1950 invention of optical pumping, and Dennis Gabor's 1947 invention of holography (yes, 1947, before lasers, which stimulated development of lasers)

[https://en.wikipedia.org/wiki/Optical_pumping](https://en.wikipedia.org/wiki/Optical_pumping)

[https://en.wikipedia.org/wiki/Dennis_Gabor](https://en.wikipedia.org/wiki/Dennis_Gabor)

<comment><USER10> Interesting. On following up on your links, I see that while optical pumping was invented first, Townes was able to make the first maser by using an electric field to separate out an excited state of ammonia, achieving a population inversion without pumping. [http://home.fnal.gov/~kubik/FermilabWebsiteDocs/Masers.ppt](http://home.fnal.gov/~kubik/FermilabWebsiteDocs/Masers.ppt)

The closer you look, the less the history of innovation looks like a simple sequence.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Sadly, I think there are some confounding factors to the lack of success in this story. If this is the same manner in which the author communicates a scientific theory to the community, it's not exactly surprising it hasn't been received well.

Perhaps it should be that science is entirely disconnected from how it's presented and who by; but in reality, it is still a human pursuit, and in order to be successful at it, you need to appeal to other humans, and you need to do it well. This is true of basically all pursuits involving social groups.

This is, of course, highly critical after reading only a single data point, but it's probably a contributing factor to the frustration here.

<comment><USER12> It's unfortunate, but cranks are a natural occurring human thing. In the grand scheme of things, it's probably for the best that we use higher level cues as to the value of a work, than exerting a large amount of effort digging deep.

<comment><USER13> "Very unfortunate!" and a knowing look appeared on the faces of all those present'.

</comment></comment></comment><comment><USER14> Flagged because

\- there is serious evidence of crackpottery, as evidenced by other contributors

\- there is little evidence of good science, as evidenced by other contributors

\- there is little evidence of good review (either of content or of prose), as evidenced by other contributors

\- in the absence of all of those, one would fall back on the credentials of the author, which seem to be minimal

\- _Super Physics for Super Technologies_ is self-published (via Amazon CreateSpace)

\- the forum seems very bizarre for this subject

I don't think this article is worth HN readers' time to read and consider, and I'd taken its presence on the front page as an endorsement by the community. I want my time back.

<comment><USER3> The huffington is HN related right? Maybe OP linked as a satirical commentary on their content policy?

<comment><USER14> I do sort of dislike that there's no good way to include commentary along with a link. But I don't think "Look at this piece of trash that HuffPo posted" would be particularly great HN content, either.

</comment></comment></comment><comment><USER15> A stark contrast from the days when Lee Smolin (author of _The Trouble With Physics_ [1]) lamented that your career in physics is essentially dead unless you went into string theory, and pursuing quantum gravity could lead to conflict with pro-string peers. And I don't think he was imagining it. Here's one reviewer:

"In the context of string theory, he literally floods the pages of his book with undefendable speculations about some basic results of string theory. Because these statements are of mathematical nature, we are sure that Lee is wrong even in the absence of any experiments." [2]

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

[2] [http://motls.blogspot.com/2004/10/lee-smolin-trouble-with- ph...](http://motls.blogspot.com/2004/10/lee-smolin-trouble-with-physics- review.html)

<comment><USER16> The motls blog claims that Smolin made provable mathematical errors in his book. Do you disagree?

<comment><USER17> I cannot speak to the mathematical errors, but I recommend you take most of what Motl says with a grain of salt. He is well known in the physics and mathematics community for a variety of interesting statements, including my personal favorite: "Discrete math is just a disorganized mess of random statements." [http://www.scottaaronson.com/blog/?p=1720](http://www.scottaaronson.com/blog/?p=1720) Which is interesting, because I have yet to see a construction of continuous mathematics that didn't start with something discrete.

<comment><USER9> Motl is an infamous pain, and makes enemies at the drop of the hat, and is extremely scornful and overly negative -- but he's also intelligent and knows mathematical physics.

I would disregard his unsupported _opinions_ out of hand without thinking twice, but not his supported arguments, whether right or wrong.

</comment></comment></comment></comment><comment><USER18> The author only encountering to 10^500 sting vacua/landscape issue in 2013 raises some serious crackpot alarm bells [0]. That was common knowledge in the community by 2005 at the latest.

[http://math.ucr.edu/home/baez/crackpot.html](http://math.ucr.edu/home/baez/crackpot.html)

<comment><USER19> Yet FWIW, note that #39 applies to _every_ string theorist!

"39\. 50 points for claiming you have a revolutionary theory but giving no concrete testable predictions."

</comment></comment><comment><USER20> When physicists can't be employed as physicists they go into finance right? So all of the unemployed string theorists will go into finance?

<comment><USER21> Most of them already have. The number of strings postdoc has already slowed to a trickle.

</comment></comment><comment><USER9> Given the brief text, I'm not clear on how t' Hooft's idea is different than orthodox GR:

> Prof. Gerardus 't Hooft had brought up something interesting in his 2008 > paper "A locally finite model for gravity" that "... absence of matter now > no longer guarantees local flatness..." meaning that accelerations can be > present in spacetime without the presence of mass. Wow! Isn't this a > precursor to propulsion physics, or the ability to modify spacetime without > the use of mass?

I don't know about the speculations, but the basic question of curvature in the absence of mass is totally orthodox general relativity.

It's a very widespread folk myth, even with physicists, that absence of matter means asymptotically flat spacetime, but it's not absolutely true.

I had thought John Baez discussed this on sci.physics ages ago, but after I couldn't find that, this is the first formal reference I dug up to support that:

"Relativity And Geometry" by Roberto Torretti, 1983

Page 199: Chapter 6, Gravitational Geometry

> First several new non-flat matter-free solutions of the field equations have > been discovered, which show that an empty universe built in accordance with > General Relativity can be a very lively place, the interplay of pure > gravitational energy being enough to produce some remarkable phenomena if a > handful of test particles is supplied.[31]

[footnote [31] on page 334 discusses "Friedmann's equation", with a limit tending to 0 in the case of interest]

Maybe the point is that the orthodox stuff is usually concerning an empty universe solution? I had thought there were non-empty universe solutions that behaved this way as well, but I might be misremembering.

<comment><USER18> Massless GR is sometimes called "pure gravity", and is something people are still interested in (or were, last time I was paying attention) [1]. Kind of remarkable that even the base-case has so many open issues. I should re-read that Torretti book, I remember liking his style but that some of the math was over my head at the time.

[1] [http://arxiv.org/abs/0706.3359](http://arxiv.org/abs/0706.3359)

</comment></comment><comment><USER22> This article on theoretical physics misspells "Nobel Prize" three times.

<comment><USER23> Yep, it is a "Noble Prize".

Also, "The Founder & Chairman, Solomon completed a 12-year study into the physics & engineering of Gravity Modification"

"Solving gravity modification and doing it in 12-years is a very significant achievement as Michio Kaku's estimate was 'several hundred years' (April 2008 Space Show interview)."

Sauce: [http://xodusonefoundation.org/about- solomon/](http://xodusonefoundation.org/about-solomon/)

</comment></comment><comment><USER24> Besides, in 100 years we will be fortunate if anyone will be alive, let alone doing theoretical physics.

</comment><comment><USER25> Yeah, I'm going to go read an article about string theory in the fucking Huffington Post, because I hate myself.

Seriously, why is the Huffington Post not banned as a source here?

<comment><USER26> It used to be, but occasionally a substantive article shows up there, so we moved it up a level to penalized-but-not-banned.

</comment></comment><comment><USER27> That's got to be the most inadvertently HN-clickbait headline I've ever seen.

<comment><USER28> Having a personal vendetta against 'string'ly typed programming, upon seeing the headline, my head involuntarily perked up like that of a meerkat.

(The OP headline was previously "Strings Are Dead")

<comment><USER29> Same here, somehow I was picturing a realization (that strings are wrong) so large that even the HuffPost would write about it.

</comment></comment></comment><comment><USER30> "I forecast that both string and quantum gravity theories will be dead by 2017."

I was listening until this. What is the basis for this statement? Whenever I've made a statement trying to forecast the future by a date, I've been almost always wrong.</comment>


How Enums Spread Disease – And How to Cure It (2012) - <AUTHOR> http://codecraft.co/2012/10/29/how-enums-spread-disease-and-how-to-cure-it/

<comment><USER2> Seems to me that the whole point of OOP is programming is to encapsulate this information. An enum is basically just a degenerate class. If you're finding that you are doing a case on your enum all over the place, you should probably be defining them as objects (or possibly subclasses).

The solution of creating a bunch of tuples (or structs)...well, that's just creating a bunch of objects. The language and paradigm already has a way of dealing with these that's a bit more flexible and powerful than tuples.

<comment><USER3> > The solution of creating a bunch of tuples (or structs)...well, that's just > creating a bunch of objects.

Essentially in Java that's actually what you're doing, and if you override the constructor of the enum you get a nice version of what the author is describing (but with more flexibility than a straight up Map)

(oh, bthornbury covered this in his comment)

</comment></comment><comment><USER4> I was nodding in agreement throughout the article until the solution was presented, or at least the implementation of it. Maybe it's truly genius and am I just not understanding it properly, but the fact I had to go over it multiple times to grasp wtf is going one isn't exactly a good sign, I think.

The idea behind the solution is definitely ok: you define a type with a bunch of immutable properties describing it. But surely there must be more elegant/easier to read/easier to understand ways to do this than to have a bunch of macros/includes inside enums and whatnot? Moreover the TUPLE macro is declared twice with the same arguments (and then the arguments are repeated once more) so that means extending the type has to be done in 2 places which is exactly one of the things warned about earlier.

<comment><USER5> This is exactly why I am really happy to be working in a language which doesn't support macros. Are they performant? Yes. But they absolutely ruin code readability and make debugging harder also (as you're stepping through "code" which only exists post-compile).

I felt like the OP made a great point about enums and I agree.

<comment><USER6> They do have downsides, but you gloss over the main reason to use macros; they're an extremely powerful tool.

<comment><USER5> Meh. People are expensive, compute is cheap. If code is twice as hard to debug, you better have a darn cost saving reason to be working in inefficient language like C/C++.

<comment><USER7> Macros really aren't about performance, though (or at least they shouldn't be; inlining and/or constexpr are a better solution to that problem in basically every respect). They're either about simple, potentially extremely unsafe, syntax extensions (as in the article) or about using metadata that wouldn't otherwise be available (e.g. filenames/line numbers in the assert macro).

Not that I think macros are a good thing– 99% of the time they're best avoided– but dismissing them because 'performance isn't important' is basically a non sequitur.

<comment><USER8> Plenty of languages provide filenames/line numbers in assertions without using macros.

Furthermore, `__LINE__` and `__FILE__` style macros are a pretty safe subset of macros that aren't really representative of the problems with macros. Compare:

        #include <stdlib.h>
        #include <stdio.h>
        #include "my_macro_library.h"

        int main()
        {
            int x = 0;
            printf("%i", increment(x));

            printf("%i", __LINE__);

            return EXIT_SUCCESS;
        }

There are a ton of different implementations of an `increment` macro which are going to cause undefined behavior here. Contrast with the `__LINE__` macro: it's implemented by the compiler and has unsurprising, well-defined behavior.

</comment></comment></comment></comment></comment></comment><comment><USER9> So in other words, only use Enums to declare a set of 1-dimensional items that can't be broken down further (i.e., item is a property, not an object). Otherwise, you are going to run into trouble.

Isn't that kind of the definition of an Enum vs. Struct vs. Class/Object? And the problem lies with what enums are being used for in some cases, rather than enums being a bad practice?

<comment><USER10> Depends on the language. Java enums can hold arbitrary attributes (the "cure" is built-in), and algebraic data types go significantly further as variants can have completely different fields.

</comment></comment><comment><USER11> This is a good look at the dangers of diffusing semantic knowledge in general. His approach is much more true to OOP paradigms.

In Java, you can take this a stop further, and use enums basically as enumerated instances of a class. Example:

public enum Stuff { Stuff1(param1), Stuff2(param2);

        private Object param;
        private Stuff(Object param){
            this.param = param;
        }

        public getParam(){
            return this.param;
        }

}

Now you can call Stuff1.getParam();

<comment><USER10> > In Java, you can take this a stop further, and use enums basically as > enumerated instances of a class.

Isn't it half the point of java's enums? (the other half being type-safe enums).

</comment></comment><comment><USER12> The solution presented here basically consists of implementing a VehicleType class with a bunch of static instances without using the class syntax. I can't decide if this was a deliberate decision from the author or if he just didn't realize this.

<comment><USER13> Maybe to be C-compatible?

</comment></comment><comment><USER14> I guess the way to solve this disease is just to use Enum for what they are supposed to be used for. Which is storing a state, that's it.

This article really lacks of OOP concept. In the first example the enum is a property on the 'vehicule' object, it would be way better to add all the properties needed to that class instead of creating a weird 'VehicleTypeTuple' struct...

</comment><comment><USER15> In my experience, most of the evils of enums can be traced back to the lack of exhaustive pattern matching in C++/Java. When programming in Rust or Haskell, enums are used much more often, and the exhaustiveness enforcement by the compiler means that these kinds of use cases tend to be encapsulated inside helper functions, which end up being equivalent to the members of the "tuples" presented by the author. Any additions or changes to the enum will automatically make the compiler force you to update these functions.

</comment><comment><USER16> The title is a bit misleading--maybe 'plain enums'. In Java for instance, all the _solutions_ can all be encapsulated within the language's 'enum' type.

<comment><USER17> I second that; Java has solutions for all problems described by this post.

\- constructors, private fields, methods, addressing the "separations of concerns" \- how about Enum.valueOf(enumClass, text.toUpperCase()) to avoid the "classic shadow array of string literals"?

Here is an example of what can be achieved by Java enums

      enum Type {
        ANIMAL(null),
        MAMMAL(ANIMAL),
        DOG(MAMMAL) {
          public void makeNoise() {
            System.out.println("Woof");
          }
        },
        CAT(MAMMAL) {
          public void makeNoise() {
            System.out.println("Meow");
          }
        };
        private Type parent;
        Type(Type parent) {
          this.parent = parent;
        }
        public boolean isA(Type type) {
          if(this == type) return true;
          if(parent != null) return parent.isA(type);
          return false;
        }
        public void makeNoise() { }
      }
      assert Type.DOG.isA(Type.MAMMAL) == true;
      assert Type.CAT.isA(Type.DOG) == false;
      Type.CAT.makeNoise(); // "Meow"

<comment><USER18> This demonstrates a different problem - enums are closed. If I want to add an Owl, I can't do it without editing Type. This might break the API contract (if you own the library) or not be possible (if it's a third part library).

There is very little reason to use an enum over classes in this example. It's rare that I've seen a Java class style enum that wouldn't have been better served by classes (including some that I've written myself and regretted!)

<comment><USER19> For this example, I agree that it makes very little sense. The question you really need to ask yourself whenever you are making an `enum` is: Does it make sense that this type is restricted to a predefined selection of instances? There are times when the legitimate answer to this question is "yes", and in those cases go ahead and make an `enum` and enjoy its benefits.

<comment><USER20> Historically, I've used rich enums in Java to be able to use switch statements to reason about a system state and as poor man's type pattern matching. Sometimes the switch is handy for making a state machine clearer, and sometimes it makes it easier to explain the relationships of these states as an ordered list. Another important use of enums is if you're trying to create a rich set of annotations that take parameters, which would force you into dropping a lot of the Java OOP typing available. I can't have a closure or even an anonymous class as an argument to parameterized annotations - and this is definitely by design.

I got bit pretty hard before trying to design an annotation-driven convention for a library I was writing (I had been writing a lot of Python for a while) and realized I'd have to squash a bunch of my carefully arranged classes into an enum. You run into similar problems when marshalling your objects to, say, a Thrift structure definition.

</comment></comment></comment></comment></comment><comment><USER21> This does not read to me like good advice from an experienced programmer.

</comment><comment><USER22> It has been a while since I wrote Java, but if my memory is correct, Java has a much cleaner solution to this. In Java an enum is just a class with a fixed number of instances, each with a constant name. You can make the instances private and expose all of your behavior through the interface of the class, using a "factory" method to find the correct instance (I say factory in quotes because it doesn't create the instance, it just finds the correct instance, which already exists). There's nothing stopping you from doing a switch-case against the instances, but at least if someone does that it will be limited to the enum class. And with some discipline you can define all the properties in the enum's constructor so no switch-cases are necessary. This mitigates all the OP's concerns, I think.

In C# you can use extension methods to keep all your switch-cases in one place, but it takes a little more work to enforce this with private visibility. I haven't thought through this completely, but my first attempt might be to replace the enum with a class with a private constructor and expose public static const instances, or maybe even hide the instances behind a factory method. I haven't tried this in practice, however, so I'm not sure what the implications of that approach are.

</comment><comment><USER23> Why not simple subclasses? E.g. class Truck extends Vehicle. From the article, the argument would be that "everything in one file" is desired, so you can e.g. parse it from other or for other languages.

There are also the downsides of the table approach. What does avg_km_per_liter mean for e-cars? With multiple classes they can have different fields.

Everything is a tradeoff.

</comment><comment><USER24> This _is_ the standard style of programming in functional programming languages. While it isn't object-oriented (being its dual), I don't see why is it so bad (I wouldn't like a single `Vehicle` class to have methods handling lane use in each state).

</comment><comment><USER25> One of the antipatterns I see in db schemas is over-use of just one field to indicate status or action, if not both. It's the same basic deal of overloading enums as the article demonstrated -- every instance increases your pain of complexity.

So, I guess, that's to say, this is a little bigger than just enums.

</comment><comment><USER26> Often called an X-macro

[http://en.m.wikipedia.org/wiki/X_Macro](http://en.m.wikipedia.org/wiki/X_Macro)

</comment><comment><USER27> Shouldn't this all be in a config file or vehicle database in the first place and not hardcoded?</comment>


Show HN: Birdy – Micro-blogging engine - <AUTHOR> https://github.com/MLstate/birdy

<comment><USER2> A great sample application which showcases a state-of-the-art parsing engine.

</comment><comment><USER3> The main question is : Why should I use your micro-blogging engine instead of the other ones? The README is unclear about it.

<comment><USER4> > Birdy is the main application described in detail in the O'Reilly Opa Book.

To learn more about Opa.

<comment><AUTHOR> That's indeed the best answer.

Another one is that, Opa should provide by default a pretty good level of security, being immune to XSS attacks and database injections.

Edit: looking at alternatives, it might also be one the cleanest...</comment></comment></comment>


Jetpack to the WP.com Cloud - <AUTHOR> http://jetpack.me/2011/03/09/blast-off/ <comment><USER2> I wish WordPress would use unique names for their software releases. Didn't they just have that namespace collision with Django? It's great that they checked with Mozilla before using the name "Jetpack", but it's still going to confuse some people if used without the prefix.

<comment><USER3> There's no namespace collision here. The word _namespace_ has a specific meaning; it doesn't just mean whatever you want it to mean.

<http://www.wordnik.com/words/namespace>

</comment></comment><comment><USER4> I was expecting a simple Heroku-style scalable cloud hosting solution for Wordpress with one-click deploy from wordpress.org. A few plugins that wordpress hosts doesn't seem like that exciting of a feature :\

<comment><USER5> Same here. The use of the word "cloud" here is a misnomer and feels very strange coming from a group of folks many of us previously assumed were above that sort of hype.

I'm confused why someone would want to run the decidedly hamstrung version of Wordpress if they have the option to run the "real thing"?

For example, Wordpress.com blogs do not allow JavaScript of any kind. They make decisions like this to better be able to handle the scalability of their hosted offering, and for that it's entirely logical, if not a bit annoying.

Would the Jetpack version of Wordpress be similarly locked down? Of course you could make tweaks to it to do whatever you want with it once you host it on your own, but then again, why not just use the full wordpress.org version?

Open-sourcing a few plugins that were previously only available to Wordpress.com users would be just as nice, but I guess then the ability to put the word "cloud" in big type doesn't fit as well.

<comment><USER6> We're trying to remove all the barriers you used to have to hosting WP yourself, from ease of upgrading to the cool social features on WP.com that are in or coming to Jetpack.

</comment></comment></comment><comment><USER7> "I already use a plugin that is now part of Jetpack (such as WordPress.com Stats). What do I do now? As we upgrade each of our individual plugins to be a part of Jetpack, we'll prompt you to switch over to the new, Jetpack-powered version."

What I'm reading here is that I'll soon be dropping Wordpress.com stats entirely. I don't want a bloated plugin like Jetpack when all I need from it is the stats plugin. Thanks but no thanks.

</comment><comment><USER8> FAQ: _Some individual features that Jetpack provides will be free, but others in the future may require payment._

</comment><comment><USER6> I don't know if people will fully understand Jetpack yet, because it's early -- like the iPhone 1G. But this is the most significant release Automattic has done yet, in my opinion.

<comment><USER9> it seems like this is just a group of hosted plugins. what am i missing?

</comment></comment><comment><USER10> Has anyone else interpreted this title + link like this:

Jetpack to the WP.com Cloud: Jet pack me!</comment>


A leak wounded LabMD. Fighting the Feds finished it off - <AUTHOR> http://www.bloomberg.com/features/2016-labmd-ftc-tiversa/ <comment><USER2> _Daugherty believed signing a consent decree would give doctors the impression that LabMD had been lax in protecting patient data and kill his business._

Well duh. LabMD violated patient privacy after all:

 _The manager of the billing department had been using LimeWire file-sharing software to download music. Without knowing it, she'd left her documents folder, which contained the insurance report now in Tiversa's possession, open for sharing with other users of the peer-to-peer network._

<comment><USER3> It was one employee of tiversa who discovered the folder. It was the tiversa leader Boback who then used that as an excuse for extortion, lying about the extent to which it was 'in the wild' (it wasn't). When daugherty fought back, sensing the scam, boback sicced the govt on him, who then stupidly just gobbled up whatever tiversa claimed. Tiversa is the company that needs to be crushed. LabMD had a very bad stroke of luck in one very very stupid employee. I hope daugherty wins both lawsuits, against the corrupt govt. and the pos co. tiversa.

</comment></comment><comment><USER4> >> The path of least resistance was to settle...

It's hard to fight the bureaucratic beast.</comment>


Wgpu-rs on the web - <AUTHOR> https://gfx-rs.github.io/2020/04/21/wgpu-web.html <comment><USER2> This is why Rust is going to eventually eat Javascript's lunch on the browser. I'm willing to longbets that by 2025 we see a Rust framework as the top browser toolkit. I'd even be willing to bet that there are popular frameworks in use by major websites that discard the DOM altogether for something simpler and faster.

There's a reason why this has to happen, too.

My sincere hope is that Mozilla and the Rust/Browser luminaries will develop cross-platform APIs for full device hardware abstraction. If we can get Rust/WASM to be able to access the same system calls, hardware resources, payment APIs, native windowing routines, etc. as the iOS and Android SDKs, then we can potentially build a cross-platform native web that is just as snappy as the two shitty walled gardens we have today.

I really hope the performant web slays the app store. That's the dumbest trap we ever fell for. I'd love to visit a website and be playing native Minecraft in seconds. Sans Google Play or the App Store, with no bullshit monopoly tax.

That would address one of the major problems in our industry.

<comment><USER3> > I really hope the performant web slays the app store. That's the dumbest > trap we ever fell for. I'd love to visit a website and be playing native > Minecraft in seconds. Sans Google Play or the App Store, with no bullshit > monopoly tax.

I don't, unless certain criteria are met.

There is a consumer-friendly side of apps that is often overlooked in these types of conversations: generally, I get to decide when to update my apps, and the developer can't uninstall their app off my phone without my permission. Moving from apps to the web shifts the balance of power even further from user to developer.

There are some apps (that require internet access) for which this is not true. For those, I share your sentiment; spotify has no reason to be an app. It's also possible to implement this amount of user control with the web, by caching the full version of a page, when you add it to your home screen (for example), and only replacing it after an explicit prompt (as a setting, ie auto-update).

Until that happens, though, I don't wish for the death of app stores. Especially, f-droid is a great ecosystem.

<comment><USER4> Even though I agree with the benefits of having control over updates seeing how popular SaaS has become I find it quite likely this will happen to (many kinds of) Apps as well.

</comment></comment></comment><comment><USER5> I could really do with a diagram to explain how all the parts fit together. gfx-rs, Vulkan, wgpu-rs, wgpu-native, browser WebGPU, gfx-hal, Vulkan Portability bindings.

Here's what i think:

1\. Vulkan is an API for doing graphics which is modern and standard

2\. Direct3D (part of DirectX, the names are sometimes used interchangeably), Metal, and OpenGL are APIs for doing graphics which are modern _or_ standard

3\. Vulkan, Direct3D, Metal, and OpenGL are all implemented by graphics card drivers and operating systems working together - this is pretty much the bottom of the software stack

4\. gfx-hal (along with gfx-backend-*) is a Rust library which abstracts over Vulkan, Direct3D, Metal, and OpenGL; its API is similar to Vulkan, but not identical

5\. The Vulkan portability bindings implement Vulkan (the "universally portable subset") on top of gfx-hal (to an extent - it seems like there are lots of little bits that can't be implemented for each backend)

6\. WebGPU is an API for doing graphics which is modern, standard, and easier than Vulkan

7\. WebGPU is (or soon will be) implemented directly by browers, on top of who knows what, Direct3D etc i suppose

8\. wgpu-core is an implementation of (a Rust projection of) WebGPU on top of gfx-hal

9\. wgpu-native is a C API on top of wgpu-core

10\. wgpu-rs is a nice Rust API on top of WebGPU, which can (now!) use either a browser's WebGPU, or wgpu-native

gfx-rs is the name of the overall project.

I'm sticking to text mode.

<comment><USER6> So its silicon -> OS driver -> Vulkan -> gfx-hal -> wgpu-core -> wgpu-rs

Anyone has an idea how much performance those layers of abstraction cost?

<comment><AUTHOR> Both wgpu and gfx APIs try to avoid any significant CPU usage in hot rendering/compute paths (e.g. by doing more work upfront instead of during rendering), so generally the performance cost should be fairly low for most applications.

The Vulkan API is basically 1:1 with gfx-hal so the performance cost should be negligible when gfx-hal is running on top of Vulkan. There is some overhead when running on top of other backends (such as Metal or DX12) versus implementing separate backends for wgpu, but the design of WebGPU avoids most places where the overhead would become significant anyway.

Similarly wgpu-rs only adds Rustier bindings to wgpu-core, so any performance cost should be negligible.

There is some amount of overhead in WebGPU in general (caused by automatic memory management, additional resource tracking, etc.) versus directly using raw Vulkan/DX12/Metal, but WebGPU tries to find a good balance here between security/portability/performance/usability.

</comment></comment></comment><comment><USER7> One of the things that use wgpu-rs is Iced[1], a cross-platform GUI Library inspired by the Elm Architecture.

Although the project started around May 2019 and is still highly experimental, it looks like they got a lot of progress made and things look promising! The interest seems incredible: they have 5.4K stars on GitHub (amazing for such a young project) and there are lots of impressive examples[2].

As someone who just learned about the project: hope this takes off!!! A lightweight, simple to use GUI toolkit that can run on the browser and desktop is really something developers desperately want.

[1] [https://github.com/hecrj/iced](https://github.com/hecrj/iced) [2] [https://github.com/hecrj/iced/tree/master/examples](https://github.com/hecrj/iced/tree/master/examples)

<comment><USER8> I was just playing around with Iced yesterday, it is indeed very nice. I wish it has better docs though.

</comment></comment><comment><USER9> This is very cool stuff. I'm waiting a bit for it to become more mature, then I'd like to use it as the basis for druid, a native Rust UI toolkit. As noted in another comment, iced is already doing that.

One of the reasons I'm excited is that I believe I can get very high performance, and high quality 2D rendering using an evolution of the techniques explored in the piet-metal prototype. This work extensively uses GPU compute capabilities, which are not available in older versions of OpenGL or in WebGL.

</comment><comment><USER10> Can it do sha3 hashing in a web browser on the gpu?

<comment><USER11> Yes, so does WebGL and with the same efficiency.

Partial hash inversion is an embarrassingly parallel problem: computing a hash from a random number is independent from the other random numbers you want to compute hashes for, also it is a computation bound problem and not memory bound. It means you can build a fairly efficient partial inverse finder by running many fragment shaders ("pixels") in parallel and only drawing the one that finds it. This is doable in WebGL today.

A key feature of WebGPU is compute shaders which sound like they can compute stuff so they would be better at hashing. But actually compute shaders give more flexibility which makes it possible to handle problems that are a bit less parallel, and they help optimize memory-bound programs (but don't help for computation bound programs). So compute shaders make it slightly less code to do a partial inverse finder, but do not make it dramatically more efficient.

So to answer your implicit point: no WebGPU won't unlock capabilities that will lead to a rise in ads mining Bitcoin. (though it could maybe help for Ethereum mining)

<comment><USER10> Can you share an example or tutorial?

<comment><AUTHOR> There are some resources for wgpu-rs linked from the blog post (such as [https://sotrh.github.io/learn-wgpu/](https://sotrh.github.io/learn-wgpu/)).

There are also some tutorials available that demonstrate how to use the browser API directly:

\- Raw WebGPU [https://alain.xyz/blog/raw-webgpu](https://alain.xyz/blog/raw- webgpu)

\- Get started with GPU Compute on the Web [https://developers.google.com/web/updates/2019/08/get- starte...](https://developers.google.com/web/updates/2019/08/get-started-with- gpu-compute-on-the-web)

</comment></comment></comment></comment><comment><USER12> This is really cool. I've been excitedly watching how wgpu is developing. I don't have much graphics experience outside of one ogl but it looks like it's turning into something seriously neat.

<comment><USER13> Definitely. The last time I did any truly serious graphics programming was in the early noughts and the fact that I can now toy around with a really modern graphics stack in a reasonably straightforward, cross-platform yet still performant way is really wonderful.

I've been enjoying my time with wgpu-rs so far and I intend to keep doing so.

</comment></comment><comment> lachlan-sneff I think that wasm potentially has a great future for cross-platform binaries. Eventually, hopefully, the same code that can run in a browser will be able to run natively on linux or macos without recompiling.

A major blocker for this is that wasm applications are slower than native ones. There are a few reasons for this, and some of them, like simd support, are slowly being fixed, but an important one in my opinion is that memory in wasm requires bounds checks.

Now, there are hacks to make that fast, but they work for wasm32 and not wasm64. I think architectures adding instructions for lightweight memory sandboxing would go a long way to alleviate this problem.</comment>


Does Pizza Deserve To Be A Vegetable? - <AUTHOR> http://tpmdc.talkingpointsmemo.com/2011/11/does-pizza-deserve-to-be-a-vegetable.php <comment><USER2> Is everyone forgetting the fact that a tomato is a fruit and not a vegetable?

<comment><USER2> Nevermind, from Wikipedia: The U.S. Supreme Court settled the controversy on May 10, 1893, by declaring that the tomato is a vegetable, based on the popular definition that classifies vegetables by use, that they are generally served with dinner and not dessert (Nix v. Hedden (149 U.S. 304)).

<comment><USER3> Most people think that there is some kind of scientific classification of fruit vs. vegetable, and that the Supreme Court went with popular usage over science.

That's not actually so. Fruit is an overloaded word that has both a botanical meaning and a culinary meaning. Vegetable does not have a botanical meaning (except sometimes it is used as a synonym for "plant").</comment></comment></comment>


More than 200 Videos from Defcon 15 Hacker Conference - <AUTHOR> http://www.catonmat.net/blog/videos-from-defcon-15-hacker-conference/

<comment><AUTHOR> i should have been in bed 3 hours ago...</comment>


Pictures of the Dutch Cafe Energy-Generating Revolving Door - <AUTHOR> http://www.inhabitat.com/2008/12/10/energy-generating-revolving-door-by-boon-edam/ <comment><AUTHOR> Originally discussed here: <http://news.ycombinator.com/item?id=385806>

However, this link includes photos of the revolving door and a link to the actual cafe.

<http://www.natuurcafelaporte.nl/>

Also, the 4600kWh / year figure originally quoted is the total energy _savings_ versus a normal sliding door; not just the energy generated.

<http://www.boonedam.us/inc/press/pressdetail.asp?PressId=182></comment>


Microsoft's latest HoloLens demo is more realistic about its limitations - <AUTHOR> http://www.theverge.com/2015/7/8/8914815/microsoft-hololens-demo-video

<comment><USER2> Is verge a legitimate source for technology-related news? Seems like they're very pro-apple and anti-everything else

[https://www.youtube.com/watch?v=CI5xnkLk8IA](https://www.youtube.com/watch?v=CI5xnkLk8IA)</comment>


A farewell note to a programming language - <AUTHOR> http://matthiasnehlsen.com/blog/2014/12/04/Farewell-Scala/

<comment><USER2> On Monday I'm giving a talk at Scala Exchange on my take on idiomatic Scala. For those of you who can't make it, I'll give a quick rundown. You basically need four patterns:

\- algebraic data types

\- structural recursion

\- fold, map, and flatMap

\- type classes

That, in my experience, will cover the majority of code you need to write in Scala and give a solid basis for a robust and comprehendible code base.

It's unfortunate that in Scala algebraic data types and type classes require a bit more code than in most other functional languages.

E.g.

       sealed trait Foo
       final case class Bar(...) extends Foo
       final case class Baz(...) extends Foo

vs something like

       data Foo = Bar ... | Baz ...

for an algebraic data type, but it's really not so onerous to type.

These patterns are really truly shockingly simple to use. We teach them in introductory courses and the majority of people get them.

It's true that Scala has some warts, but as software engineers we ought to make decisions based not on our personal biases but on a consideration of the problem domain and tradeoffs involved. If you want 1) static typing, 2) a modern language, and 3) JVM compatibility then Scala is the best choice at the moment IMO. Remove one of those restrictions and other choices come into the picture.

Update: If you're interested in learning more about these patterns, on Friday we're going to send a free excerpt of our "Essential Scala" book to our mailing list. The excerpt will include material on algebraic data types and structural recursion. You can sign up here: [http://underscore.io/newsletter.html](http://underscore.io/newsletter.html)

<comment><USER3> I think you just described Haskell in your four bullet points (which I'm sure you know, or at least know of.) Of course it comes with the baggage of pervasive laziness, so there's that potential objection...

It can't run on the JVM, but to be honest, I've never actually observed in practice what's so great about the JVM (if you're running functional code). Everyone I hear claims that the JVM is great (left & right), but I just don't see it. Maybe I'm just ignorant.

<comment><USER2> The true benefit of the JVM is the ecosystem. There is a load of ancillary stuff like database drivers and web frameworks, to more exotic stuff like rendering PDFs, that every application needs. It doesn't add value to work on this stuff yourself but you can just about guarantee there will be on the library on the JVM that does what you want. It might not be pretty but it will exist somewhere.

This is particularly the case in the big data space, where all the major frameworks are run on the JVM.

For many people, interfacing with legacy Java code is also important.

And yes, I advocate using Scala much like Haskell.

(There is also the performance of the JVM, which is pretty good, but this is only a point worth mentioning when comparing to languages like Ruby and Python. Most functional languages have good compilers and runtimes.)

<comment><USER3> Honestly, the IME the JVM ecosystem isn't _that_ great. I think you could probably find a bigger/better ecosystem for C/C++ at this point in time. (Even going as far as Big Data or PDF support, but I know nothing of the former.) I recognize that the JVM has (for several years at least) been sold on this premise, but I just don't think it's true, or at least not true to the extent that the PR says.

Don't get me wrong... it's _good_ but _not_ great (in my conception of things). Even if you find some indispensable JVM-based library, then why not just shell out to an executable jar (or whatever) that does what you need? At least you'll avoid classpath-hell that way.

<comment><USER2> Maybe, maybe not, but I had three criteria and C/C++ certainly don't meet the other two. (There are other criteria we use when making these kinds of decisions, like performance, speed of development, availability of developers etc, but I thought we were talking about modern functional languages so I didn't bring these up.)

I think the language that hasn't the biggest chance of upsetting the JVM is Rust. Mozilla talk about Rust as a C/C++ replacement, but I actually expect they'll see more interest from JVM focused developers. A lot of current systems programming uses the JVM (all the aforementioned big data systems like Kafka, Cassanda, HBase, etc.) A number of these systems have issues with the JVM, particularly GC performance on large heaps, and Rust would be very attractive here. Scala developers in particular are used to modern language idioms and so could relatively easily switch to Rust.

<comment><USER3> > (There are other criteria we use when making these kinds of decisions, like > performance, speed of development, availability of developers etc, but I > thought we were talking about modern functional languages so I didn't bring > these up.)

Oh, indeed -- and I might even agree on the non-platform arguments. And I'm not discounting those -- I'm just saying that the JVM (not Java/Scala/Groovy/whatever) argument is overstated :). IMO, as always.

Agreed about Rust as well, I think. Java programmers are already used to the verbosity (tongue firmly in cheek ;)).

EDIT: Actually, come to think of it... many of the criteria you mentioned would apply to JavaScript developers, wouldn't they?

</comment></comment></comment></comment></comment></comment><comment><USER4> Interesting. I've followed Matthias' project as I've tried learning the Play framework as well as front end development, and it has been incredibly useful. Incidentally, I learned Scala after I knew Clojure reasonably well, and I feel like I could apply the same arguments in the reverse direction.

When it comes to the back end, I'll likely choose Scala 100% of the time. I really believe there is no substitute for a strongly typed ML-derivative for that type of environment. Additionally, there are a strong set of robust scala libraries (Typesafe mostly) that are completely production ready, and java interop is much more natural when you need it.

For the front end, I'm currently using Javascript, but I have toyed with the idea of both Scala.js and Clojurescript. This is where Clojure really makes me mad. I feel as though the dynamically typed Clojurescript should be a better fit as a compile-to-javascript language, but in every instance I've tried, Scala.js just works better. It compiles correctly, error messages make sense, much better documented, and there are fewer deviations from the core language. And the clojurescript libraries are mostly terrible in this regard...even the super-hyped ones like Om. My biggest pet peeve are the tutorials that force you to learn unrelated things (like Datomic, Emacs, Ring, etc) to be able to walk through them. I really feel like Clojurescript had a chance to shine here, but I find it far less inspiring than the relatively immature Scala.js. Oh well.

</comment><comment><USER5> If you like Scala but find it too scattered then there's always Haskell* :)

(*) Not that there aren't a thousand reasons to not choose Haskell. This is merely obligatory temptation dangling.

<comment><USER6> It's official. Haskell has become the Beowulf cluster of Hacker News.

<comment><USER7> Beowulf cluster?

<comment><USER8> It's an old-school Slashdot meme: "a Beowulf cluster of X", where X = commodity hardware, microprocessor, or Furby.

</comment></comment></comment></comment><comment><USER9> I found your experience closely mirrors mine with scala. At my current shop we write mostly ruby and scala. The ruby code between developers looks much more uniform than the scala code I believe due to the fact that while trying to please everyone scala hasn't yet developed much of "the scala way". I do hope this changes as I really enjoy scala. Currently my team is experimenting with style/punting tools like stylecop to try to bring a little consistency to our code. Too early to say how it will work out but I would love to hear from others how you try to bring a team style to a code base that will happily let a fully functional developer, a fully object oriented developer, a straight imperative developer, and someone who believes in mixing these things all work side by side. Mentally by giving up the possibility of nothing you have to learn everything which means loading a lot of the scala compiler up into your brain before even trying to read a bit of anyone else's code.

<comment><USER10> Mixing an imperative developer with a functional developer? That's asking for trouble. You'll have to be converting between mutable and immutable data structures anywhere the two interact. Or forcing the imperative developer to be largely functional due to the immutable data structures everywhere that prevent him from using imperative approaches. Or forcing the functional developer to write in a largely imperative style due to the mutable data structures that prevent copying from being efficient, and can be mutated any time they pass out of his/her code.

Or to put it another way; Scala as an idea may be fine; you can mix imperative and functional together, by picking which data structure and approach for a given problem is 'right'. But in a team environment? Touching someone else's code in a particular paradigm means you have to be familiar with, and expect, that paradigm. You can come up with a team that agrees on what paradigm everything must be written in (and that can be anywhere on the continuum), but you can't mix and match and expect developers to not have to learn every paradigm in use.

<comment><USER5> The ST monad would like a work with you :)

<comment><USER10> Which doesn't help the imperative programmer who is having to interact with functional code.

And an ST monad makes no sense unless you're interacting with imperative code (obviously, hence your bringing it up), which means you already understand what imperative is, and are still having to convert your immutable structure to a mutable one, for the imperative code to operate on, and to recognize it will be modified in place; to use the ST monad the functional programmer already has to understand imperative programming.

It also seems like it would fail to encapsulate the side effects an imperative function may have, since that function is able to interact with state elsewhere, that isn't actually encapsulated. I.e., the ST monad makes sense when dropping into update-in-place for performance reasons, but when there are side effects that are not ensconced within the monad (remember, the function you're calling was written by an imperative programmer, in a language that allows side effects outside of a monad; not Haskell), the ST monad does nothing to make it functional, and oh crap, now your functional programmer has the same problems as an imperative programmer, in having to figure out WTF this function just changed in some other imperative chunk of code, in some other process or object or whatever.

So given imperative and functional paradigms, even using the ST monad, if the functional code is to call the imperative, and the imperative is to call the functional, both the functional and the imperative developers have to understand the other paradigm, -and- deal with the considerations of both. You've upped the complexity of your system considerably.

<comment><USER5> It doesn't allow free crossing between an (imperative + mutable) world and a (value-centric + immutable) world, no. It, instead, allows for clear boundaries to be set between the two and each to be embedded into the other.

The ST monad also does exactly restrict the scale of effect of mutability which can occur. It's not a license for the imperative programmer to do whatever they want---it's a license for them to solve problems in the way they prefer within a particular ensconced region.

If you want, you can write a program where everything lives inside of a giant ST monad layer. You always do this if you replace ST with IO, in fact. Each bit which can be made purely functional will be embedded into this monad and, for sake of sanity and testing, those functional bits ought to grow and grow.

But it doesn't really demean the IO/ST segment. An imperative programmer can live happily there without much trouble at all.

<comment><USER10> "It doesn't allow free crossing between an (imperative + mutable) world and a (value-centric + immutable) world, no. It, instead, allows for clear boundaries to be set between the two and each to be embedded into the other."

I wasn't saying you couldn't set boundaries; you have them implicitly simply by dint of the fact that in Scala, mutable/immutable is based on the type, and the type system is enough to enforce that. But now you have a performance penalty being introduced based on who works on a given part of the code, and one that can easily compound.

"It's not a license for the imperative programmer to do whatever they want--- it's a license for them to solve problems in the way they prefer within a particular ensconced region."

But for the imperative programmer to know what not to do he/she has to understand functional coding, and choose to eschew certain techniques that might be viewed as acceptable from a purely imperative perspective.

Please note, I didn't say you -can't- do it. Just that it's asking for trouble, and that either you have to understand both paradigms or you suffer a performance penalty (converting from mutable to immutable and vice versa). And that if you ever want to touch someone else's code you have to be familiar with the paradigm. Not proficient, but enough to realize what you have to do to be able to interact with it properly/safely, that that requires a broader depth of knowledge on the part of each team member than if you picked one paradigm, and that leaving them to know only their paradigm will not work. The imperative person has to figure out higher order functions, working with immutable data structures, etc, to make use of some of the stuff the functional guy has written, and the functional guy has to be comfortable with destructive updates, side effects, etc, to be able to make use of what the imperative guy has written. Yes, they both can interface with the other, but what they have to know is much broader, and every time they interact you risk bugs and performance penalties that you'd not have if you picked one paradigm alone.

</comment></comment></comment></comment></comment></comment><comment><USER11> I think the article is fundamentally flawed from this comment alone:

"In well over a year of working in Scala teams there hasn't been a single day where I felt that there was a shared mindset about how to develop a system or even approach a problem."

So this guy expects a programming language to create a shared mindset?

I've been developing software for close to 17 years in more languages than you can shake a stick at and none of them do this for you. It's always about picking the right tool for the job and/or team.

A shared mindset comes from other planning type activities like use cases, function/non-functional specifications, and general architecture type planning before you write code. Especially for larger projects.

I think software patterns tend to help drive synergy in a team environment. It's not perfect but my experience has shown me and the folks I work with at least, that adopting patterns helps to bring us together but those patterns are usually fleshed out during architecture planning activities.

<comment><USER12> I think there's a huge contrast between a language like Perl, where There Is More Than One Way To Do It, and say Python, where "There should be one -- and preferably only one -- obvious way to do it."

<comment><USER13> "The Zen of Python" makes a number of lofty claims like that, but the actual language design doesn't embody them well if at all. To pick an example off the top of my head, there are three syntaxes for string literals (single quote, double quote, triple quote) and three prefixes (raw, binary, unicode) which can be combined in a number of ways. As a result python offers 15 ways(!) to express a string literal.

<comment><USER14> That's really disingenuous. The "Zen of Python" is not bragging on the part of Python, but an expression of values in a community.

<comment><USER15> His point is that those values don't exist in most of the community as exemplified by their code and blogs, and this is largely because the language encourages straying from those values.

I should note that I agree, and I'm a Python dev full time.

</comment></comment></comment></comment></comment><comment><USER16> A programmer complains that different programmers have different styles of programming in Scala ...

and ... switches to a lisp. You know, languages that execute code by rewriting the syntax tree of the running program ...

This ought to be good.

This is not meant to be disparaging against LISPs. I'm just alluding to the fact that while there are 5-10 ways to do the same thing in Scala, all looking very different, working subtly different, there's 5000 different ways to do the same thing in LISPs.

<comment><USER10> Every list of best practices, for every LISP, agrees that macro use is generally a "use rarely" thing. And Clojure seems to have developed idioms around simplicity.

Scala, on the other hand, has wildly diverging sets of best practices. The feature set is huge, attempting to appeal to pure functional programmers in their academic ivory towers, and the grizzled Java developers who believe OOP is the one true way, and everyone in between.

It's easy to -say- that there are 5000 ways to do the same thing in a LISP, and only 5-10 ways to do the same thing in Scala (both statements being hyperbolic, presumably; there are infinitely many ways of doing each, after all), the meaningful variations you are likely to see in the wild are far, far lower in Clojure than Scala. And will likely be based on different understandings/expressions of the problem, rather than on different language subsets that the author prefers.

<comment><USER17> > Every list of best practices, for every LISP, agrees that macro use is > generally a "use rarely" thing.

Not really. This best practice is for beginners and mid-level programmers. They either write macros for the wrong purpose or in problematic ways. Thus they should avoid macros. Still they need to use macros, since languages like Common Lisp provide a lot of functionality through macros.

To get past that stage a book like 'On Lisp' by Paul Graham helps.

Many, but not all, advanced programmers will use and write a lot of macros.

<comment><USER18> Thats just not true in clojure. Good librarys in clojure have a data interface, function to produce that data and maybe a thin macro layer to make it a little more easy to use.

While 'On Lisp' is a cool book, I rarly find the really advanced macro stuff usful. Once in awhile, you want to have something like a really good pattern matching compiler, and then your macros come in handy. But day to day, you dont need them much.

<comment><USER17> Let's look at some Common Lisp example:

[https://github.com/Wukix/LambdaLite/blob/master/lambdalite.l...](https://github.com/Wukix/LambdaLite/blob/master/lambdalite.lisp)

This is a recent tiny in-core database.

The code is using LOTS of macros. It also implements a few non-trivial macros. Half of the code is implemented as macros.

Code like that is not unusual in Lisp.

</comment></comment></comment></comment></comment><comment><USER19> His Clojure implementation is here: [https://github.com/matthiasn/BirdWatch/tree/master/Clojure-W...](https://github.com/matthiasn/BirdWatch/tree/master/Clojure- Websockets)

</comment><comment><USER19> fogus, what should I read nowadays? BOOKS???

[http://blog.fogus.me/2011/03/27/the-long-lost-art-of- thought...](http://blog.fogus.me/2011/03/27/the-long-lost-art-of- thoughtfulness-in-blogging/)

<comment><USER19> Ok found the answer [http://michaelrbernste.in/2014/10/21/should-i-read- papers.ht...](http://michaelrbernste.in/2014/10/21/should-i-read-papers.html)

</comment></comment><comment><USER20> Well, OK.

</comment><comment><USER21> There are three and only three vague points conveyed in the article: (1) Scala has "immense" syntax, (2) Scala tries to support too many paradigms, and (3) the Iteratee library is hard to grasp.

For (1): I disagree -- Scala's syntax is relatively easy to grasp. Perhaps the author meant constructs.

For (2): people keep saying this but why not just stick with the way you are comfortable with?

For (3): I don't see how this is a language issue; at the very least it shows that the author is unable to grasp a particular functional programming abstraction.

<comment><USER22> (1) I think you can safely assume that he means constructs. If he has spent years writing Scala he has surely grasped the syntax. (2) A team may have many people with different feelings about what they are comfortable with. This raises problems in an enterprise environment. (3) I can only guess that he feels the library is so hard that many developers with struggle with it.

I think Go is an interesting language partly because they seem to keep it simple by choice.

</comment></comment><comment><USER23> No offense to the author, but this reads like a 16 old claiming he finally find the girl who is 'the one' for life. __only two years later__, that Another girl shows up and OMG the new chick definitely is the 'true' one.

To put it another way, under extreme circumstances, Mr. Martin Odesky can use even the $& _^%$#_ $ PHP to write safe and efficient airplane flying control software.

The point is the language is hardly matter as much as your kids think. There are far more important things for good software. But language is not only a tool but also a toy and a passion, so I can appreciate the urge to talk about it. :-)

<comment><USER18> > No offense to the author, but this reads like a 16 old claiming he finally > find the girl who is 'the one' for his whole life.

I think thats what he was going for.

> There are far more important things for good software.

Everybody knows this, but people still like to talk about programming languages.

<comment><USER24> Additionally, I think what's key is to note that he wasn't pumping Clojure too hard in the post. It was more a post about why he's leaving Scala. And in that analogy, you can be pretty certain that the girl you're leaving is definitely not "the one".</comment></comment></comment>


C Closures as a Library - <AUTHOR> https://nullprogram.com/blog/2017/01/08/ <comment><USER2> [https://www.gnu.org/software/libffcall/](https://www.gnu.org/software/libffcall/) does exactly this - libcallback - but for all architectures. It's used in CLISP.</comment>


Show HN: AppApp.io – A better search for the iOS App Store - <AUTHOR> https://appapp.io <comment><AUTHOR> Hello HN. Please take a look at my project.

As to why the world might need another search for the App Store, I have written a blog post here: [http://blog.appapp.io/post/131747237960/the-raison- detre-of-...](http://blog.appapp.io/post/131747237960/the-raison-detre-of- appappio)

</comment><comment><USER2> Are you scraping the App store or is there any official API from where you have fetched this data ?

<comment><AUTHOR> The data comes from numerous sources. Some of which are:

\- iTunes search API: [https://www.apple.com/itunes/affiliates/resources/documentat...](https://www.apple.com/itunes/affiliates/resources/documentation/itunes- store-web-service-search-api.html)

\- iTunes Enterprise partner feed: [https://www.apple.com/itunes/affiliates/resources/documentat...](https://www.apple.com/itunes/affiliates/resources/documentation/itunes- enterprise-partner-feed.html)

</comment></comment><comment><USER3> I love this. I can't stand in app purchases on kids games

<comment><USER4> Same here - My two kids always hit the purchase and advert buttons in their games and get angry that their game has gone away.

</comment></comment><comment><USER5> This is freaking cool!

Why isn't this on the front page?</comment>


Why Did America Give Up on Mass Transit? (Don't Blame Cars.) (2018) - <AUTHOR> https://www.citylab.com/transportation/2018/08/how-america-killed-transit/568825/ <comment><USER2> viruses

We don't want to get sick. Individual cars keep us away from people who would cough and sneeze on us.

Shutting down mass transit would really slow down virus outbreaks.</comment>