Modern China Is So Crazy It Needs a New Literary Genre (2016) - <AUTHOR> https://lithub.com/modern-china-is-so-crazy-it-needs-a-new-literary-genre/ <comment><USER3> > First, the history is different. Chinese civilization has an unbroken > history of five thousand years.

Despite that this is a inspired article, this sentence still interrupt my immersive reading. Such claim has always been ridiculous to me, but it is still too often spoken to be ignore. Chinese has unique own point of view to their history, which includes legends and myths. Check this ( [http://camphorpress.com/5000-years-of- history/](http://camphorpress.com/5000-years-of-history/) ) if you have interests.

<comment><USER4> I mean, strictly speaking everywhere has exactly as much history as everywhere else.

As for China, there was a concerted and largely successful effort to destroy its cultural heritage during the "Cultural Revolution", by the party that remains in power today. Hardly unbroken.

<comment><USER5> Are you saying the Cultural Revolution has largely destroyed China's cultural heritage? If so I'll have to disagree with you.

<comment><USER3> China did lose many.

Let's take religion as an example. In Malaysia, Taiwan, and Singapore, traditional temples are still "alive" with popular and active ceremonies, while most temples in China I went are just dead buildings: people lived there and do things have nothing to do with divine, CCP-permitted official events, foreign tourists, modern decorations that have no integrity, etc.

It's just sad to see those religious sites dying. The spiritual essence died, during exactly the Cultural Revolution.

<comment><USER6> Why is that a bad thing? Religion has been the cause of much strife. Sure, you miss the nice parts when it's gone. But I take one look at other societies that still fight over this arbitrary "faiths" which make no scientific sense and it makes me wonder if it isn't a simpler world to not believe in the superstition of religion ( or at least treat it that way legally)

<comment><USER7> Its interesting that Buddist religions don't appear to encourage strife per se, my knowledge of asian religions is very spotty, but I don't think they have the same wars and justification for violence as the western religions do.

<comment> saiya-jin Look at Sri Lanka, very bloody civil war between Buddhist majority and Hinduist minority. Atrocities done on both sides, ie at the end when rebels were losing and surrounded, state army was shelling civilians left and right. Another example - history of Ladakh province in northern India - conquered by buddhist armies some +-1000 years ago. Buddhist army, interesting term.

I also had this view that buddhism is a faith that promotes peace - <USER2> might be true, but you still have the same human beings behind it. History proves my naive idea wrong.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> There's a short mention about food safety and how ordinary citizens worry about this - I'm in the USA and I and the people I know always inspect the food we eat for country of origin and never purchase anything from mainland China. On the one hand factory farming in the USA means we have to worry about stuff like e coli and safe food handling but that pales in comparison to the risk of feeding your children lead or melamine because the producer was purposely trying to pinch pennies.

<comment><USER9> What kinds of food have you found to have been made in China?

<comment><USER10> Many products in Asian supermarkets are made in China - we try to buy from brands that manufacture in other Asian countries if possible, or the USA.

Some examples: \- spices and condiments for chinese cooking, \- seeds, nuts, and canned vegetables that are not common here \- asian meat preparations like fish ball, vietnamese beef ball

<comment><USER11> I did that until I discovered the Lao Gan Ma (Old Godmother) brand of chili sauce.

It's just too good to care.

<comment><USER12> Is this the stuff with the little garlic bulbs in it? What's a fair price to pay?

<comment><USER11> They have a couple different flavors. My favorite is the one with peanuts in it. I don't recall seeing garlic bulbs.

It looks like this:

[http://nymag.com/strategist/article/lao-gan-ma-best-chili- sa...](http://nymag.com/strategist/article/lao-gan-ma-best-chili-sauce- review.html)

At Asian supermarkets, they should be less than $5. I usually see them them at Ranch 99 (a Chinese chain supermarket) for 3.99.

But the price can vary if you go to a predominantly Korean or Vietnamese supermarket.

</comment></comment></comment></comment></comment></comment><comment><USER13> Is it just me or do all of these things seem very reasonable, even tame by novel standards? All of the examples are exciting stories, but nothing that doesn't show up in your standard action movie.

<comment><USER14> The difference is that you don't _just_ know that it has actually happened, but also you are footing the bill for it.

As a Russian I find chinese ultra-unrealism pretty wimpy. We've got cooler, more fierce stuff.

<comment><USER15> Are there forums / collections of Russian ultra-unrealism? Ideally with English transaltions -- would love to read some but I don't understand Russian.

<comment><USER14> You could probably start from The Moscow Times, though they are rather softcore.

[https://themoscowtimes.com/articles/krasnodar-judge- throws-2...](https://themoscowtimes.com/articles/krasnodar-judge- throws-2-million-dollar-party-58405)

Then nobody was sure that this judge had ever study law. She said she went to some college in Georgia (the country) which said she's not on their records.

</comment></comment></comment></comment><comment><USER16> Is "cyberpunk dystopia" truly insufficient?

<comment><USER17> Maybe if you dial the "punk" down to zero, dial the "dystopia" up to 9, and maybe "cyber" is around 3 or 4 depending on how futuristic modern day China is.

<comment><USER18> Orwellian dystopia with a hint of cyber

</comment></comment></comment><comment><USER19> Shades of [https://www.goodreads.com/book/show/21413849-nothing-is- true...](https://www.goodreads.com/book/show/21413849-nothing-is-true-and- everything-is-possible)

</comment><comment><USER20> for the record, that's a picture of hong kong, though it is a part of china, it's not representative of where most of these "stories" happen

</comment><comment><USER21> This was a great article. Usually I get a distinct "translated from Chinese" vibe, but not here! I thought that the translation must be very good. Can Anyone who has read the original comment?

<comment><USER22> Agreed. The only thing that really jumped out at me as "translated from chinese" was the "As you all know" (I assumed translated directly from 众所周知)

</comment></comment><comment><USER23> Any rapid growing/evolving country is a crazy and super-dangerous/disastrous evolution. You can't evolve fast and well, you can't avoid mistake when changes happen and the more concentrated changes the more mistake you'll get...

Often after some time evolution start to became for reaction an involution and if people in that country are lucky evolution+involution result after some time in a new stability "golden period", but that's rare...

</comment><comment><USER24> Does anyone have a link to the original Chinese?

<comment><USER25> Possibly [http://www.bjwl.org.cn/wwwroot/bjzjw/publish/article/657/530...](http://www.bjwl.org.cn/wwwroot/bjzjw/publish/article/657/53058.shtml)

Edit: actually, the English version appears to have been adapted significantly, providing details that would either require no explanation for a Chinese audience, or that could get the author into trouble with the authorities. But the version that the translation was actually based on might not be public.

</comment></comment><comment><USER26> Interestingly, while reading the text and with zero knowledge of the novel he's talking about, I always assume the text's author to be a woman. Does anybody know the guy? Are his novels also like this?

</comment><comment><USER27> China does need a modern religion for expansion of the influence sphere, not just literature, that's why the officials are in touch with Vatican.

</comment><comment><USER28> This article on China's recent crazyiness doesn't mention its long-standing oppression of minorities. It looks as though getting at the obvious root of the obvious problem is not on the table.

That said, there's plenty of madness at loose in the world. When we in the US get our own house cleaned up, finger-pointing will see less absurd.

<comment><USER29> .. could we have just one humanist piece about life in China without people breaking out the battle axes? We don't shoehorn the Iraq war into everything about America.

We could do with a lot more understanding and a lot less context-free outrage if we're gonna get through this century with the peace intact.

<comment><USER30> Actions that cost lives should always be front and center.

Maybe we _should_ be talking more about the Iraq war in the USA, considering our actions led to the death of hundreds of thousands of people.

I contend the opposite: The only way to survive the next century is if we identify sources of death and misery, and (try) to hold leaders accountable to stamp them out.

<comment><USER29> The Chinese government has overwhelmingly reduced death and misery within their borders. Half a billion people moved from third world to first world. Half. A. Billion.

And their big foreign policy power play consists of building infrastructure for other third world countries. Turns out you can do that for 10 countries cheaper than invading one.

Yet the popular opinion ever since dragonfly was proposed is that they're the worst country ever. How about some perspective?

<comment><USER31> The needs of the many outweigh the needs of the few, eh?

<comment><USER29> More like: Life is complicated and not black and white.

The Chinese actions in Xinjiang are an overreaction, and wrong, but:

1) Every western country has an equivalently bad record regarding reaction to terror attacks and/or separatist movements.

2) Nobody in the tech community cared until the dragonfly thing came up and they all went on wikipedia looking for reasons to hate China.

The way people talk about China these days reminds me of McCarthyism more than humanism. I have to wonder, if China were less successful, and the people were poorer, would they be less upset? They're fine with buying cheap goods, after all..

<comment><USER32> > Life is complicated and not black and white.

vs. stuff like

> yet the popular opinion ever since dragonfly was proposed is that they're > the worst country ever.

and

> Nobody in the tech community cared until the dragonfly thing came up and > they all went on wikipedia looking for reasons to hate China.

Nobody cared? Went on Wikipedia looking for reasons to hate China? Is anyone allowed to guess about the causes of such sophistry, or does that just go one way?

<comment><USER29> Check the record. We didn't have 3 hate pieces a day on China hitting the front page of HN until dragonfly.

Maybe you want to take a crack at why?

<comment><USER33> It's not hate pieces to talk about building military bases out of nothing in international waters, claiming they are now your territory, kidnapping the head of Interpol, kidnapping people in Hong Kong and other countries who write and complain about China. It's the truth.

<comment><USER29> Ok, you're not wrong, but you could make similar-caliber complaints about any of the rest of the UN security council. Or Israel. There's a whole cottage industry writing about them.

How come China specifically rockets to the top of HN whenever someone finds some negative press? And why did it start after dragonfly was proposed?

<comment><USER33> I do point out issues with other countries, like Isreali settlements, us supporting Saudi Arabian war in yemen. China is a lot more powerful than most other countries (like the us) and needs to stop acting like a bully, as the us needs to be careful to do too.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER34> > 3) It is has the quality of a fable or an allegory. Reality itself has the > quality of a fable.

In recent years I have been seeing this over and over, not just in China but also in the West. Two examples are the rise of Trump and Brexit.

<comment><USER35> Well we forget history. Can you imagine how bizarre the Russian revolution or World War I would have felt to someone living through it?

</comment></comment><comment><USER36> This sounds a lot like Pelevin's turbo-realism to me. It's probably not a coincidence that that movement arose in early post-communist Russia, when the present were similarly unmoored from the past.

</comment><comment><USER37> This should have a 2016 tag :)

<comment><USER38> The article this was translated from was written in 2015

<comment><USER39> That's important, because China hadn't rolled out the "social credit" system back then.

China has a new approach to control. It's not Orwellian. It's not the USSR's. It's not a police state. It's a new thing. It's the gamification of authoritarianism.

The previous system of control was run through the "work unit", when almost everybody worked for the state. The party mostly acted through work supervisors, rather than cops. That started to come apart once there were more private employers. The social credit system is an attempt to get back that level of control. It's going to be interesting to see how this works out.

<comment><USER40> > It's the gamification of authoritarianism. ... It's going to be interesting > to see how this works out.

And like all gamification systems, it's already being gamed.

The citizens and enforcers who figure out the tricks win, everyone else suffers, and resentment builds.

<comment><USER41> good,china needs a regime change.their status quo has been propped up artificially for too long

<comment><USER39> By what? China's 5-10% annual growth in standard of living makes up for a lot.</comment></comment></comment></comment></comment></comment>


How to Create Data-Driven User Interfaces in Vue - <AUTHOR> https://blog.rangle.io/how-to-create-data-driven-user-interfaces-in-vue/ <comment><USER2> comment not related to this article but more of a comment on data-driven user interfaces in general.

Building simplistic data driven UIs is (relatively) simple.

However, the issues arise as these get more complex. Instead of just needing to understand a thing, you now need to understand the engine which builds that thing.

Looking at the react community where the new hotness is also data driven everything. UI definition (incl. CSS) all now detailed in JSON(which each original author custom builds), a lot of time without constraints(..'cos flexibility)

Building a data driven anything without having a very strong focus on debug- ability right from the get go is doomed to fail.

</comment><comment><USER3> Very insightful tutorial, thank you Evan</comment>


Getting Stuck While Doing TDD, Part 3: Triangulation to the Rescue - <AUTHOR> http://www.tddfellow.com/blog/2016/08/31/getting-stuck-while-doing-tdd-part-3-triangulation-to-the-rescue/ <comment><USER2> I'm pretty fastidious about following TDD practices, and I am very careful to cover as much program state as the language I'm using reasonably allows.

However, my mental model for approaching TDD I think is much simpler than the approach presented here. It basically is:

Do I _really_ understand the design implications of the unit I'm about to develop?

\- No: Play around and prototype, and learn about my design, don't worry about tests

\- Yes: Throw away any prototype and then really do the unit test-first.

I found that I gravitated towards this process after I learned (partly thanks to blogs from Uncle Bob Martin) that unit tests are really formal design specs. They are so formal and specific that they are expressed in code- a program describing what your program does. Before you can write one of those (or as many as your unit needs), you need to have a very precise concept of how you are about to proceed, and what exactly the product code is about to do.

The benefit of this process is that I prefetch a really deep understanding of the system I'm building. This leads to less bugs, and it leads to sensible, well-documented, and meaningful tests. It just takes a bit of discipline to follow at first, when you're not used to working this way.

Some argue that it takes longer to write code this way, especially when I throw away my hard-earned working prototype! It does take a little longer at first, but:

\- Once I know the answer/outcome I seek, the tested version comes out way faster than the prototype.

\- I spend much less time later on fixing my own bugs, which I learned are mostly due to my own lack of understanding the full dimensions of my system's design.

<comment><AUTHOR> This is a pretty interesting process you have there. I usually use throw-away Prototypes/Spikes, when I do not know how to write my first test or I feel uncomfortable test-driving the problem. Once I reach enough confidence, I remove spike's code and start test-driving it.

I let the design of the system emerge on its own, while I'm listening to how hard it is to write tests and steering the wheel using Red-Green-Refactor (2nd cycle of TDD) and while I'm following Specific/Generic rule (applying Triangulation together with Transformation Priority Premise) (this is the 3rd cycle of TDD).

Red-Green-Refactor on its own indeed is very well known for leading quickly to the local maximum of the solution and its design. 3rd Cycle of TDD breaks out of the local maximum of the solution to the problem. 4th cycle of TDD breaks out of the design maximum (4th cycle of TDD - Hourly, we step back and look at the overall design and architecture of the system, taking a careful look at the architectural boundaries and seeing if we are about to cross any of them with our efforts, we proceed with informed decisions steering to the right design we want for the next hour).

Here is the Robert C. Martin's blog post on the cycles of TDD: [http://blog.cleancoder.com/uncle- bob/2014/12/17/TheCyclesOfT...](http://blog.cleancoder.com/uncle- bob/2014/12/17/TheCyclesOfTDD.html)

</comment></comment><comment><USER3> I started with XP in 99 after seeing the wars on OTUG, and then made great use of the TDD approach, I was busy using TDD to build real systems by first getting legacy systems under test and then progressively refactoring and introducing new functionality. At the same time on the mailing lists a lot of the XP consultants started advocating quite "pure" approaches. At first it was "as a learning / thought experiment", but a curious thing started to happen in the 2000s, "Agile" developed a doctrine and religion about it and the free flowing thoughts that were pushing how to design software better started to dry up. A lot of the TDD advice out there at the moment is from the religious stage of Agile.

Here's my take-aways on TDD...

\- It' about designing software through feedback

\- Code should compose together easily, refactor till it does, be mindful of the tiny details

\- Test as little as possible (or I think Kent said "as is Responsible"). The tests are there to validate your intent and provide feedback. Tests are liabilities that need to be maintained, so only maintain good ones.

learning TDD? do it on throw away problems, play around with how small the steps you can take are. Play around with refactoring, don't have have preconceived ideas about the solution. TDD learning problems with other people. Pay attention how it changes how you design something. Do some bigger things, start noticing the problems of TDD, especially when dealing with outside frameworks and systems.

Production TDD? It's a tool and may help provide design ideas or help stitch together preconceived design ideas, use everything in your arsenal to design and create good software, there are no rules or doctrine. But understand as many tools and "rules" that the software community offers and the reasoning behind it. Collaborate with others to create and design, and make sure you have quick feedback cycles. Be quick to recognize new ideas, tools, and techniques that either provide feedback or designs.

<comment><USER3> oh, one other thought, if you are a TDD advocate and TDD all the time and are quite productive. Try this, code something without tests. A curious thing occurs, your software mostly works fine, it's often correct straight away. Basically, you learnt how to design and code. The tests are just feedback. The code itself should also be surprisingly testable if you wanted to test it (if not, still lessons to learn about design and coding). Now, since you are coding and designing pretty well without tests, pay attention to what actually breaks. Gives you a good idea about what kind of Tests are important. Then think about the minimal test that would have stopped you making the mistake.

<comment><USER4> I think what led to the religious zeal currently is that OO/mutable state programming is a house of cards. On a team, everybody can be a great coder, but just one bug can bring the whole thing down in a non-trivial manner. I'm guessing it was easier simply to say "TDD All The Things!" than try to split hairs and work with the nuance.

<comment><USER5> This seems to be anathema in some circles, but perhaps the team (in the abstract) is the problem here. Rather than bending over backwards to make software development team-friendly, might it make more sense to have individual module owners and well-defined interfaces between modules?

(Trying to compartmentalise the mutable state wouldn't hurt, either...)

</comment></comment></comment></comment><comment><USER6> I missed Part 1 so I went back to Part 1 of this series and I have to say, I don't agree with this approach at all. By only writing the simplest/most naive solution to get your tests to pass maybe you are saving unnecessary work, but I feel like most of the time, and certainly in this example, you're just deferring work you know you're going to have to do. So instead of doing the work as you go through the tests you're pushing it all off to the end and then having to write the whole class in mostly one go.

If instead you wrote what's necessary to pass each test properly as you went, you'd be building the class incrementally, and importantly you'd have a series of commits which each have worthwhile code in them instead of a bunch of useless slop.

<comment><USER7> Kent Beck talks about Triangulation in Test Driven Development by Example as just a tool to break out when you are stuck. He doesn't recommend it for every situation, but recommends it when you hit a road-block and need to back off and work around it.

<comment><AUTHOR> While this is true, using this technique all the time makes me damn effective with it and I very rarely get stuck (only when I actually violate one of the rules).

And I like the BabySteps feel that it produces, it is so nice to evolve your code bit by bit one test at a time and without harming Semantic Stability (you can read about it here: [http://blog.cleancoder.com/uncle- bob/2016/06/10/MutationTest...](http://blog.cleancoder.com/uncle- bob/2016/06/10/MutationTesting.html) )

</comment></comment></comment><comment><USER8> Programming by evolutionary process. You may get to the solution eventually, but damn if it's the slowest and most brain dead way to get there. Potential for falling into local minimum is so great it strikes me as almost a fraud.

Do people really pay for this kind of work?

<comment><AUTHOR> Yes, they do, and pretty good.

Because it is actually faster and less error-prone once you get familiar with Evolutionary Design.

A good read from M. Fowler: [http://martinfowler.com/articles/designDead.html](http://martinfowler.com/articles/designDead.html) \- this talks, why a lot of Extreme Programming practices come into the synergy to make Evolutional Design effective (and not only). Drop enough of these practices, indeed, it will stop being effective.

</comment></comment><comment><USER9> Building a sum method.... I get that these techniques should scale to real problems. I hate that I have never really seen them do so.

<comment><USER10> Yet real system design is usually so complex that no single technique can cover it. I shudder when I hear TDD proponents claiming that this technique can even be used for emergent design. An amusing example is Ron Jeffries's Sudoku solver attempt:

[http://ravimohan.blogspot.com/2007/04/learning-from- sudoku-s...](http://ravimohan.blogspot.com/2007/04/learning-from-sudoku- solvers.html?m=1)

<comment><USER9> Yes, that is a particularly poignant set of posts. I am still fond of dancing links to solve Sudoku, and I can't easily see how I would have found that through TDD.

And yet, among the most agreed ideas you can ever make in popular programming circles is that you are fond of TDD...

<comment><USER11> In my experience tdd is useless for discovering algorithms. It is however very useful for implementing them. I've implemented dancing links and i absolutely used tdd for significant parts of the design.

</comment></comment></comment></comment><comment><USER12> Bit OT but TDD works great where you have the specs for your project down to a T, but sometimes you're working on a website or project in which you have an end goal and some fair idea of what you're making but not everything is concrete and in such scenarios doing TDD can waste a lot of time (at least it did for me).

For such projects at least for my own case I have seen that an Excel driven development (Yes i just made it up) is a really good idea. Instead of writing tests and creating mocks and doing a lot of legwork I just write the function name in an Excel file, with the constraints and output in columns. Hardly takes me 1 minute since I always have the .xls file open. Then I go into a free-flying mode, creating my function and code and never think about it until the project is finally complete. I of course am mindful that I will have to write tests for it later so I do use DI and staw away from Singletons, etc.

Then when everything is ready (think v0.01), then I go back to each function in the XL file, and write a test for it creating assertions using the constraints and output I jotted down earlier. This way I'm not writing or re- writing my tests because something I hoped to use in my project has changed during the course of development.

After that it is TDD only because the v0.01 is out and now I have to careful that any changes I make don't break anything. I don't think this would work for a corporate environment but for solopreneurs and not so serious projects this can really be helpful. It does seem to work for me at least.

<comment><USER7> TDD is designed for exactly the opposite. If you have a really good understanding of problem and solution from experience, then just go ahead and do it. Kent Beck talks about this in his book "Test Driven Development by Example".

TDD does best when you need to be able to respond quickly to new knowledge as you dive into the problem domain or make changes due to migrating business requirements. TDD lets you create your abstractions using concrete evidence, instead of trying to guess.

However, I have found TDD to be a difficult skill to master. You cannot just try it out for 6 months and expect to be quicker using TDD than you are without it. Until you have a bunch of experience built up in TDD, it will slow you down a great deal - which is what you may have experienced. It took me about 18 months of continuously using TDD daily to really get a solid grasp of TDD.

<comment><USER2> I second this... TDD is a craft and is hard to master. IMO, that's a direct consequence of software being difficult to write correctly in general.

It also took me about 18 months to build up a good level of confidence and speed with TDD. I found it to be a really rewarding experience.

</comment></comment></comment><comment><USER13> I like TDD if the code is already clean and well-tested, and also if the existing test code is clean. If the domain code is clean but the test code isn't, I'll clean up the test code before TDDing the new feature. Shouldn't take long at all.

If it is not clean, but well-tested, then I need to clean the code before extending it further. Also the tests will probably be messy, I'll spend time cleaning those up if I have time. But in all likelihood I'll only be able to clean up the code this time around.

If it is clean, but not well-tested, then a test-after approach is better. Take your feature-implementing extension, and write tests for both the extension and what it's extending. Then the next time I'll have clean, well- tested code to TDD off of.

If it is neither clean nor well-tested, then I wouldn't bother writing tests at all, _for this iteration_. Instead I'll clean up the code, make my extension, and call it a day. The next time I extend that part of the codebase, I'll use the aforementioned test-after approach.

Tests take time to refine and get right. They are an added layer of security, but a much better line of defense is nice clean code that you know what it is doing at a glance. Tests will not save you from bugs, but clean code will make bugs way easier to iron out.

The prevailing wisdom seems to be to don't refactor unless you have test code to fall back on and if you don't have that, to write smoke tests.

I do not like this approach, I think if you have to deal with unclean, untested legacy code, then you need to do the work to understand it, and the best way to come to an understanding of code is to clean it up. As you clean it up, domain concepts become clearer.

Tests are a form of documentation, their intent is to help you understand the codebase. The code itself tells you _how_ it's accomplishing business objectives, tests tell you what those business objectives actually are. Unless you are very unlucky you should have alternative sources for that knowledge. So tests aren't strictly necessary, but they are very nice to have.

</comment><comment><USER14> > RED is as important as other in Red-Green-Refactor cycle. If next test does > not fail, it is either: already implemented, or has to wait until a later > time (until it will fail).

I strenuously disagree with this point in the following scenario: your new test could validate an edge case that your current implementation may only pass by happenstance. i.e. it's important for whomever refactors the code to pass your new test and all the old tests.

<comment><AUTHOR> If the production code does something by happenstance I will consider it a bug and fix it (unless in Legacy Code, where a bug could mean hidden super- valuable-for-customers feature). I.e.: I will make sure that this test fail and all other tests pass.

Production code doing something, that is not defined by tests is generally not a good idea, because this is clearly an untested functionality. And it has to be eradicated if nobody needs it (business and customers) or it should be covered with a test, and I want to see this test fail (by applying Mutational Testing).</comment></comment>


Programming will never be "easy". - <AUTHOR> http://mdmstudios.wordpress.com/2010/08/28/programming-will-never-be-easy/

<comment><USER2> There's actually a simpler argument, and probably a better one:

Programming can (and is!) described as an art, and it's difficult to imagine people thinking like this about _other_ kinds of art. There are few people, after all, who would say things like "Oh, one day music will be easy and everybody will be able to play like Joshua Bell." or "Oh, but one day novel writing will become easier, and everybody will be able to write like Stephen King." And so it's ridiculous as to why programming is given this treatment.

Sure, mastery of the tools in programming may be harder than in writing, say, or in photography. But tools are just one bit of it - ideas are the other bit, and much more important.

<comment><USER3> I think a larger issue lies in this:

Nowadays, any moron can take a mid-quality camera with good auto settings and do "photography", and the average customer is likely to not distinguish this person from a professional photographer with years of experience, or an established photographic artist.

Is this also true, to some degree, with programming? Can any moron who "learned java" in a first year college course compete with a good, experienced programmer because the customer doesn't know any better? (and thus will go for lower price) The answer, in my experience, is "yes".

<comment><USER4> There was a time that only experts could "make" websites (mid 90s). Today you can get a wordpress blog with a nice template and look as good as a lot of major websites. So we're partially there as far as the web goes.

I'd argue that frameworks like Rails have significantly lowered the barrier to entry for web programming. It isn't "easy" per se, but significantly easier than just 10 years ago.

</comment></comment></comment><comment><USER5> _A couple of people I have seen with have gone so far as to insinuate that the reason programming is to hard for most people, is because we design our languages to be too hard, just to keep people away from programming, and to secure our jobs._

That's like saying building engineers erecting a skyscraper in New York design their blueprints to be complex and confusing to keep other people away and secure their jobs. That's totally ridiculous. Anyone with this line of thinking is truly ignorant of the complexities and considerations required to carry out certain real world jobs.

To be a "programmer" means you can effectively communicate with, and manipulate a machine. The more direct your communication, the more you are considered to be a programmer. Microsoft became one of the most successful software companies in the world because their Windows operating system allowed anyone to become an effective _operator_ of their own computer. If you can only manipulate, but not communicate with a machine you are an operator, not a programmer. Programming the machine has not become any less complex because of the Windows GUI; it's just the complexity of managing the computer is handled by the operating system. The reason nerds will always be better at programming/technology is that we actually have an interest in the complex details of underlying technology, and putting in the time to learn. Some will even _write their own operating system_ as Linus Torvalds did, just for the heck of it. If you are someone who can't program, but wants to, roll up your sleeves and learn. Don't start making excuses diminishing the talent and skill actual programmers/engineers have attained because of your own shortcomings. That's insulting.

</comment><comment><USER6> I think he underestimates the power of domain specific languages. It may be hard to program with a general pupose language, but I think we'll soon see trees that look more like: Application -> Game -> Sports Game -> Resembles Basketball ...

And then you get a whole bunch of stuff dropped on you that starts as a basketball game, with constructs for players, scoring, fouls, etc....

Then people can come and say, "I made this new game. Like basketball, but no free throws, winners outs, dunks are 4 points, and you can tackle the player with the ball".

Sure you can't write any arbitrary thing you want, but I think most people would be happy with how far that gets you.

<comment><USER7> I remember Game Construction Kit and alike back in the day of 8-bit machines. You could build your own version of Space Invaders, only with aliens smiling and you shooting them down with flowers. Never really took off.

EDIT: this is not to say I don't see a point in your post, just that perhaps games industry is a poor example.

<comment><USER6> I agree. The game industry is not a great example. Largely because people are a lot more likley to simply by major party games. Mathematica or Matlab are probably better real world examples, although certainly not an app that Joe Plumber would use.

</comment></comment></comment><comment><USER8> As programming gets easier, the problems we will tackle will get harder. Net "difficulty" will remain constant.

<comment><USER9> _As programming gets easier_

I'm not sure this is something that's actually happening.

<comment><USER10> In the 8-bit age, you turned on your micro and had instant access to BASIC which you could easily edit line by line. Today, you have to install your SDK, maybe an IDE and learn a language a lot more complicated and deal with enormous APIs.

<comment><USER11> Today you can download python, run the installer and you get IDLE, and you can start doing some tutorials right away.

You can also download .NET and get started right away. I'm sure there are a lot more examples. It has never been easier to start learning how to program.

</comment></comment></comment></comment><comment><USER12> Programming is hard because it involves a trade-off. Programming isn't really about solving a problem, it's about limiting options until the only ones left are what people want.

I spent a few months about a year ago re-writing a massive cobbled-together database to track training, testing, and readiness for a large number of people. It had to conform to a number of requirements, like one sub-group of people's grades were averaged, but people could belong to multiple sub-groups and sometimes overlapped.

A monthly report had to be generated from all of this data. The format of the report was set in stone, and was not designed with automation in mind.

I avoided hard-coding many things as much as possible, but eventually I found that the more flexible I made the program, the more difficult it was to use. At one point you almost had to be a programmer to tell my program what kind of output you wanted.

Ah ha! So there are problems, it seems, that are fundamentally complex; there is no right answer, you can either have a flexible, complex program that accounts for every possible scenario, or a hard-coded program that is simple to use but will break the minute something changes.

The same principle applies to computer languages, spreadsheets, databases, anything. They are "easier" because they remove options from you and make assumptions that you won't miss those options. The moment those assumptions are wrong, you need a programmer.

<comment><USER13> The name I've always seen given to this is the waterbed theory of complexity. There's a certain amount of necessary complexity in a problem, and pushing it down in one place just increases the complexity necessary somewhere else. The only way to reduce the necessary complexity involved is to solve a simpler problem instead. Note that this does not exclude the possibility of unnecessary complexity, which is also possible.

<http://en.wikipedia.org/wiki/Waterbed_theory>

</comment></comment><comment><USER14> Programming will be easy when problem solving is easy.

Programming is solving problems. Some programmers would consider it fun and do it for enjoyment. But for most people programmers just solve a problem. It is just a form of engineering. A civil engineer builds a bridge, a software engineer sets up a web store.

At the bottom it is just about knowing how to organize the concepts and them build a system according the specifications.

There are tools of course: the language, the platform, programming paradigms, patterns and algorithms. A good programmer will have to be familiar with a large set of those and then pick the best for the job.

<comment><USER15> > Programming will be easy when problem solving is easy.

An especially hard part is identifying where the problems actually lie. The average person "solves" a problem by addressing only the best case scenario and lacks the pessimism and pervading sense of doom that enables programmers to figure out in advance, and account for, all the ways in which every little thing will go wrong.

</comment></comment><comment><USER16> Imagine how would you order a human to build you window with a table view, etc.

If human would not know what style of window do you want then he would ask or assume something and allowed for your comments. "Programming" humans is much more conversational. Your workers know what to assume and when to ask.

Also naming is not something that people usually do when they tell what they want to have. "Put new button in the window." I have only one window, why should I name it window1. When I will have second window I'll probably refer to this window as the first one, and to the other as second one, or other one, or the blue one. Or if everything fails I'll point it with my finger.

Programming will always be hard because deciding on what you want is hard. People can't do it at first and they need conversation to understand what they can and cannot have and decide what they want.

<comment><USER17> > If human would not know what style of window do you want then he would ask > or assume something and allowed for your comments. "Programming" humans is > much more conversational. Your workers know what to assume and when to ask.

Whenever I think about how programming _should_ work, I think about the interactions Star Trek characters have with the Holodeck in its design mode. For example: <http://www.youtube.com/watch?v=SI0wqTsIq3Q#t=3m40s> (Star Trek TNG, "Schism") — a conversation of iterated constraint-satisfaction through property alteration and library retrieval.

What you get, in these cases, is entirely dependent on the amount of context- sensitive and "common sense" knowledge the Holodeck has access to. The Enterprise on TNG was able to create a sentient being, Moriarty, from a single command, because it had access to a huge database of information about human behavior, game theory, psychology, etc. and also the complete texts of the Sherlock Holmes novels to constraint-match against.

However, Dr. Zimmerman, the programmer responsible for Voyager's EMH program, had to spend years making intricately-detailed assertions about each aspect of EMH operation—because, I imagine, the default human behaviors were no good in a medical context. Given the show's base of theory, this should have been able to be short-circuited by constraint-satisfying against a large database of holographic recordings of the performance of medical procedures, similar to the Sherlock Holmes corpus. The rest (prescribing medicine, etc.) would simply be a "friendly bedside manner" on top of the already-helpful expert system built into the computer (and it is a chronic question of why the ship as a whole doesn't just come with such a "personality subroutine" already installed—probably simply because of the show's chronic bio-centricity.)

</comment></comment><comment><USER18> Well, the main problem I have with this idea is the assumption that all Programming is equal! Which is not.

It is easy to write a simple program that concatenate 2 files for examples, it is also easy to create a CRUD database application

Systems programming on the other hand is hard, because to be good at it, you need to understand how the systems work, which is hard, and by hard I mean you need to do a lot of reading and remember many details

I believe Programming is as hard & complex as the Programming Problem domain.

Programming itself is not hard, because concepts like Iteration, functions, conditional branching, recursion, OOP (Inheritance, encapsulation, polymorphism ), etc ... are not that complex, are they?

<comment><USER19> > because concepts like Iteration, functions, conditional branching, > recursion, OOP (Inheritance, encapsulation, polymorphism ), etc ... are not > that complex, are they?

No, but stringing them all together without making an unmaintainable mess in a reasonable amount of time, for most, is.

</comment></comment><comment><USER20> I think of the problem of "learning programming" in terms of basic conceptual difficulty. Programming is difficult mainly because of "how to build algorithm," "how to design data structure" type problems. The syntax and vocab of a programming language are there mainly to illuminate concepts that keep coming up over and over in your domain, and protect you from errors.

But to solve the conceptual problems, you have to "get the picture" about various models of data organization and how they might relate to each other. If, for example, you don't know how a list works or its practical utility, you're going to get stuck at a very low level of understanding of how the infrastructure of the program might be implemented. Similarly, when you are writing software for some class of end-user(e.g. "power users" who write bash scripts daily vs. retired grandmas that are scared of any error message or complex feature) you have to design an interface around _their_ most likely mental model, so that they can get the job done quickly.

And, of course, when one programmer reviews another's code, or a programmer reviews their own code years later, the initial reaction is always that it looks ugly because it inevitably uses a thought process different from their current one.

</comment><comment><USER21> There is a problem with the example he gives, of parsing "Create a window with a table view, and then when someone clicks a button, add an entry to the table view". I think a future programming language could actually make a program out of that. I agree that there is not enough information in that sentence to be sure that the program is what the user wants, but in this case, the language can use a popular technique in programming: have defaults. For instance, most languages have a file I/O library. If you open a file without saying whether you want to read or write to it, the compiler doesn't complain, it just chooses the default. If you realize the default isn't what you want, you can change it.

Similarly, a future language could parse the given sentence as "put a single- column table view on the left, and a button on the right that says 'Add an Entry to the Table View', and when the button is clicked, just put the string Entry at the bottom of the table view". And then the programmer tries this out and tells the programming language "no, I want the button at the bottom, and it should say 'Add Person'", and the language makes the necessary changes and follows defaults otherwise, choosing to left-align the button at the bottom rather than center it, and resizing the button to fit the text. And the programmer could just keep specifying more details about what a Person is, and how you edit it, and you can make a program in this way.

Basically, this is just like modern libraries: instead of writing your own HTML parser nowadays, you can use a library with a "default" (non-custom) way of parsing HTML. In the future, rather than specifying your GUI and attached code in exact detail, you can just use a library of defaults. It will probably be the case that programmers in the future would simply move on to bigger and harder problems than GUIs with code, as gaius mentioned at <http://news.ycombinator.com/item?id=1641514>, but I think programming at the level we know it actually will get easier.

</comment><comment><USER22> Another reason to add to the pool for why programming is hard:

People don't _actually_ know what the want, nor do they know how to communicate it accurately to another person.

The day _that_ changes, it becomes _possible_ for programming to be easy because there will be an actual translation between our language and machine code. Until then, programmers are the translators, dreamers, and engineers all rolled into one. Not easy.

</comment><comment><USER23> Second sentence of this post:

 _A couple of people I have seen with have gone so far as to..._

Writing will never be "easy" either, apparently.

<comment><USER24> Yeah, and I'm not saying that blogging or writing essays was any easier.

Posting random snippets but writing worthwhile posts is a different thing altogether. I think it probably requires as much patience and effort aswell., unlike writing code which happens pretty natural.

</comment></comment><comment><USER25> The author, like many people, is conflating two issues that result in complexity in software engineering. (Among many others.)

First, is the fact that we need to tell the computer what to do. This is, I think, what the author thinks of "programming" as. He's right, it's hard, and it's gotten easier as we've improved our tools and languages that enable us to tell the machine what we want it to do.

However, second, is the problem of taking a description of a problem, from another human, and translating it into a piece of software. The source of this information, in the worst case, is a verbal description. At the extreme, it's a written specification (which, as we all know, ultimately ends up in the trash.)

It's this knowledge capture problem that I think has a wide open opportunity. There needs to be a better way for the 3rd party humans to describe their problems in a way programmers can build on top of. It doesn't have to be precise, it doesn't have to be perfect, it just has to be better than the status quo of verbal descriptions and .doc files of specs.

<comment><USER26> It's often a mistake to think that a human can describe his requirements.

People don't really know what they want.

No one could have gone to Steve Jobs and said, hey, I want a phone that can read mail, play music, download apps, and has a touch screen.

No one thinks in these terms.

At best, people would say: I want a device that I can carry around with me that can act as a small computer.

There's a wide and huge gap between "creating great products" and "gathering user requirements".

<comment><USER25> An improved means of communication would not presume to solve the problem of humans being unable to precisely describe requirements. The point is right now the status quo is that people are _unable_ to describe the requirements to a satisfactory degree of precision, for those that they _do_ have the ability to describe.

Note that this means of communication can apply not just to third parties but to those within the organization (designers, product people) who need a means to describe their own, more specific vision in terms that can be then used by programmers to turn into working software.

</comment></comment></comment><comment><USER27> From what I've seen, people find programming difficult because they lack both the ability to break a problem into smaller and smaller pieces until the pieces reach the same granularity as the language in use, and the ability to anticipate a range of possible scenarios.

<comment><USER28> This hits the nail on the head. It's not that people don't understand the syntax or even the semantics of programming languages (well, some people can't write a for loop, but they're just hopeless). It's that they can't see how to use the language to get from point A ("I want a program that does x") to point B (an actual program that does x). For instance, when I first began programming, I struggled mightily with deciding how to represent real-world data. Other people might be able to decide how to represent data, but become hopelessly stuck when it comes to turning their verbal descriptions of tasks into actual algorithms. I think that this is why so many people go on programming interviews and then can't actually solve simple programming problems: they do fine when they're taking exercises from books, but they can't concretely conceptualize the solution to an even slightly ambiguous problem.

</comment></comment><comment><USER29> Building complex things will get easier with more powerful tools.

 _Not_ building this:

<http://simpsons.wikia.com/wiki/%22The_Homer%22>

with those tools will stay just as hard.

</comment><comment><USER30> I agree. Learning the programming language is just a very small part of programming. More importantly you need to understand programmatic problem solution concepts, work-flow and maintainability.

Creating GUI's with gui editors is already there for most frameworks, but it does not make programming easier, it merrily reduces UI design effort for very simple applications (and increases hassle for more elaborate widget interactions).

As a computer programmer your biggest challenge is to understand the problem and apply your experience about problem solution logic to it via a programming language, than slap a UI on to it.

</comment><comment><USER31> Programming might never be easy, but interfacing with technology will become increasingly easy. Additionally, building simple applications will, as well; there's already a trend in that direction.

For instance, telling a server you want a blog with a theme is fairly easy.

Telling a website you want a gallery of images themed a certain way is fairly easy.

Programming might never be easy, but building simple applications -- like the one in his example -- is already easy.

</comment><comment><USER32> "Create a window with a table view, and then when someone clicks a button, add an entry to the table view"

You can almost express something like that, in SQL.

</comment><comment><USER33> Well a google search for "drag and drop programming" led me to this project:

<http://www.codeproject.com/kb/miscctrl/scriptstudio.aspx>

It looks like an UML diagram creator but instead creates basic code for simple scripts. I guess you can't write a full program with this, but it's a small step towards a greater goal maybe?

</comment><comment><USER34> What about evolution? All known life is algorithmic? Hence, given enough time, programming (coding) should be easy enough so that it could be automated. Given a suitable environment it could even spontaneously just happen. No?

Design is harder then coding because one has to define the constraints and requirements in which the program has to work.

</comment><comment><USER35> As much as I understand the points he's making, it reminds me too much of old archives of skeptical posts along the lines of "What, 12 CPUs with 32nm transistors on a single die? That will never happen, it's impossible."

Be wary of blanket statements of the form "X will never Y" (unless they break physics, and even then...)

</comment><comment><USER36> I think the task that the author is referring to is that of taking an imprecise specification of "what I want" and generating an implementation that _automatically_ resolves all ambiguities and inconsistencies in the specification.

</comment><comment><USER37> You know, I consider setting up filters in gmail to be a form a very high- level programming (DSL), and it's so easy that nonprogrammers can use them.

</comment><comment><USER38> "we don't have that type of technology quite yet"

Yet - but then don't say "never" in your title.

A true AI could probably do stuff like that.

</comment><comment><USER39> "Create a window with a table view, and then when someone clicks a button, add an entry to the table view"

The thing is, even the above has logic "then when someone clicks". A lot more logic than that is needed to write any reasonably sized program. Many conditions need to be thought of and allowed for. This is even though the above requires the computer to write a lot of code for us - which would have been originally written by humans.

</comment><comment><USER40> There's an element of symantic imprecision at play here. Software engineering is not the same thing as programming. Much the same way that furniture making is not identical to woodworking. I know my way around a wood shop well enough but I wouldn't trust myself to make a high quality wooden table or chair, as I lack the necessary expertise.

It takes a great deal of expertise to translate problems, requirements, or "stories" from user space into a design that is not only implementable but represents a good balance of optimizations and tradeoffs. This is a different skill than that needed to create the end product, a running application.

P.S. Consider: the fundamental tools make it easier than ever to be a graphic artist, or a film director. Does the fact that GIMP is free and photoshop is widely available make producing art "easy"? Easi _er_ perhaps, but there will never be a replacement for expertise.

</comment><comment><USER41> Reminds me of the classic paper <http://en.wikipedia.org/wiki/No_Silver_Bullet> from Fred Brooks where he argues that programming will always be complex because the real-world problems we're solving are complex. No programming technique or system will magically make that go away.

</comment><comment><USER42> someday your computer will be intelligent enough to handle the ambiguities of natural language as well as any human can, and then programming will be as easy as telling a good human programmer what needs to get programmed.

<comment><USER43> When we have computers that intelligent, we won't need to write any more programs.</comment></comment>


Ask HN: Is it okay to disclose your co-founder's incompetence to your employer? - <AUTHOR> Hi fellow HN guys,
A few months ago I started a company with a person (let's call him X) who was recommended by a good friend. X talked very passionately about the domain. I'm a tech guy and I have very little exposure to the domain. I thought that with X's domain knowledge and with my tech expertise we could form a synergy that would drive the company big.
We brainstormed a few ideas and decided to quickly build prototypes and iterate over our ideas. But when it came to execution, X just wouldn't do anything - wouldn't talk to clients, wouldn't talk to investors, wouldn't discuss strategy with me, wouldn't come up with a product plan, wouldn't discuss features, wouldn't do anything at all. X always made excuses of being sick or having family emergencies.
I had to align X's energy into building the company several times. After a point I realised that X was not motivated in running the company at all. When I threatened him with the idea of leaving the company, he didn't confront me. Rather, he accepted that he was not motivated and he came up with an excuse of why he wasn't able to perform.
Last month we shut down the company. Now I'm back to searching for jobs again. I'd like to know if it's okay to speak about your co-founder's incompetence to a prospective employer? I'd like to be honest with my prospective employer. I'm also willing to accept my mistake of not being able to judge a person's competency. But then again I also know that badmouthing can get me in trouble.
How do I position myself when someone asks me: "why did you close your previous company?"
PS: I've parted ways with all my previous employers on an extremely good note. <comment><USER2> It's perfectly reasonable to say something like "after working together for a few months we determined that we didn't really 'click' as a founding team and decided to go our separate ways."

That's something that happens all the time, and you won't be judged for it by any reasonably astute observer - especially for a project that only lasted a few months.

Depending on how far along you got on the project, another business savvy answer might be that the proof of concept provided the information you needed to determine that the business wasn't going to be viable (or wasn't going to be able to produce the returns you were hoping for), so you agreed not to invest further in a losing proposition.

</comment><comment><USER3> How about:

"We split the tasks among ourselves keeping in mind our strengths, but unfortunately the co-founder failed to deliver on his share of the tasks, according to him he was affected by x,y,z. (His reasons)

Then we failed to move from there and ended up shutting down the business."

Let the employer judge whether it's his incompetence or real problems. Why pass a judgement needlessly? Deliver facts.

</comment><comment><USER4> If it's for a technical position just talk about the prototype and if they ask just say your partner was focused on the business side and wasn't able to get enough initial customers to keep it going.</comment>


Self-Playing Pipe Organ - <AUTHOR> https://www.raspberrypi.org/magpi/self-playing-pipe-organ/ <comment><USER2> Most large organs are electrically controlled anyway, and the keys are just on/off switches. All those organ stops control an overly complicated combination of electrical, mechanical, and pneumatic parts which implement a switching system to change the mapping between keyboard and pipes. This is just a logic function, but implemented with century old technology it's the size of a mainframe computer.

In modern pipe organs all that switchgear is replaced with a microprocessor. Once that's done, it's trivial to add MIDI in/out, and the organ console is often just MIDI keyboards. Self-playing is a standard feature today.

The Stanford Theater in Palo Alto has a modern pipe organ, and it was deliberately built without self-play. But that's because the place is a hobby project of somebody who inherited money from HP.

<comment><USER3> Yep, the 'Durian' concert hall in Singapore, for instance, has an organ with an additional wireless console, which can be moved to wherever is most convenient. I was there as the German organ builders responsible for it were putting on the finishing touches.

What interests me about the organ in the clip is that the music, "putting on the ritz", has been slowed down. That implies that the mechanical pipe switching system must be a bit slow.

Given that this guy did the whole thing largely from first principles, neither of the above are meant as a criticism; it's a brilliant project!

</comment></comment><comment><USER4> Former church pipe organist here. I've always thought organ is a great candidate for a digitally manipulated real instrument as playing with precision and feel is NOT dependent on fine motor functions as it is for most keyboard and string instruments.

Press velocity is not correlated with volume- in fact sound is not dependent on a key press at all. Organs don't really require percussive mechanical functions for a full range of control: an idea virtual/real instrument.

<comment><USER5> Ditto Harpsichord.

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

</comment></comment><comment><USER6> > the physical engineering was more problematic

I always find amusing how dealing with physical world is challenging even if you know everything about it in theory.

Like this scene from Big Bang Theory that I use as an example in every class:

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

</comment><comment><USER7> I find it interesting that both this and Wintergatan's Marble Machine were both self-playing instruments inspired by Matthias Wandel.

</comment><comment><USER8> Finally, technology toots its _own_ horn.</comment>


How do you keep studying when you're not in school? - <AUTHOR>

I am spending my last semester in school, and I have some courses (Numerical Analysis, Knowledge Representation, Combinatorics, etc...) I wish I took before graduation but couldn't due to time constraint.
I want to be studying even when I am working as a software engineer, but I found it hard to keep motivated enough to study after work when I was working full-time as an intern. Even when the work load was moderate at where I did my internship.
I hope my study of the subject would count in case I apply to a master's degree program in Applied Math, but I cannot afford anything expensive. <comment><USER2> Talk to the teacher and ask him if you can join his class as a listener, unless you are a reknown a __hole, or have severe hygiene issues, he 'll most likely say yes. You get no voice, so if you have doubts or whatnot, Google, Books, and your own reasoning will be your only ways out. You also get no qualifications of any kind, but you don't study for the piece of paper you get at the end of the course, do you? Take it easy, anon.

</comment><comment><USER3> What works for me is to go to bed early(10pm), wake up at 6am and to study/ready/practice programming for an hour _not matter what_. The key is to set aside that hour even if there are other duties that you have to do.</comment>


What open-source maintainers can learn from antirez about customer engagement - <AUTHOR> http://globaldev.co.uk/2012/04/what-open-source-can-learn-about-customer-engagement/

<comment><USER2> We had some serious proactiveness from antirez there :)</comment>


Insights into a corpus of 2.5M news headlines - <AUTHOR> https://freedom-to-tinker.com/2016/09/14/all-the-news-thats-fit-to-change-insights-into-a-corpus-of-2-5-million-news-headlines/ <comment><USER2> I nearly skimmed over this line but it's pretty important:

"The classifier was trained by the developer using Buzzfeed headlines as clickbait and New York Times headlines as non-clickbait."

<comment><USER3> Bold and incorrect assumption.

<comment><USER4> Also amusing to me was that Reuters, Politico, and CNBC all scored _better_ than the NYT for the clickbait rating, despite NYT being used as the training data. They wrote headlines more like them than they did.

<comment><USER5> I think it is likely a (perverse) indication that the NYT is more successfully adapting and competing in the news market. But headlines have always been written with the primary intention of grabbing attention, modern web clickbait style headlines might be another evolution of that approach.

I've thought that Times article headlines have been more clickbaity over time. Some articles, especially if they aren't related to current events, are becoming more casual in their voice as well.

If they can maintain quality journalism by only sacrificing headline quality, that is probably a good and necessary tradeoff to make.

<comment><USER6> NYT is struggling to survive, made more difficult by not wanting to succumb completely to the evolutionary advancements that have made clickbait successful.

</comment></comment></comment></comment></comment><comment><USER7> I worked on the Irish version of an open source tool that looked into this somewhat.

Allowed you to pull in each article on the various news sites and stick them into git where you could then see the difference in the articles over time.

A Phd student founds some interesting insights particularly in the Irish media where content would often be changed sometimes weeks / months / years after the original story was placed online.

[https://github.com/johnl/news-sniffer](https://github.com/johnl/news-sniffer)

Often though; I found it showed how little time a journalist often had time to work on revisions to any one story....the world should lament the death of journalism.

</comment><comment><USER8> Really interesting findings on clickbait. I worry about the viability of the second half, using machine learning to detect bias (which seemed admittedly inconclusive).

> finding bias in headlines is a more subjective exercise than finding it in > Wikipedia articles...

Probably because bias from new Wikipedia users is less careful. And absent smoking guns, once you get into the gray areas, several studies have shown bias is often in the eye of the beholder:

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

</comment><comment> cha-cho I'm glad this work is being done. For kicks, I'd like to see the clickbait classifier take on /r/savedyouaclick

</comment><comment><USER9> What I'd really want is an adblock extension that automatically hides clickbait articles on, say, google news. Or maybe a crowd-sourced thing that converts titles into nonclickbait titles. People need to think of it as just another form of spam.

<comment><USER10> tldr.io might be close to your needs, but imo usually one can pretty accurately guess whether a title is intended clickbait or not (of course it helps that even if you are moderate about it in my guesstimation 90%+ of articles are easily fall in that category).

I'm on the other end of things though, I would really like a tool which can generate clickbait titles based on the article body, or even better, generate the whole fluff piece based on some keywords. Something similar to [https://pdos.csail.mit.edu/archive/scigen/](https://pdos.csail.mit.edu/archive/scigen/) maybe

</comment></comment><comment> noir-york The BBC has more clickbaity headlines than Politico, Fox, Breitbart? Really?

I think the research may need to take a second look at the algos used. Would have been interesting to have the Economist in there as well.</comment>


Stakes Are High in Oracle v. Google, But the Public Has Already Lost - <AUTHOR> https://www.eff.org/deeplinks/2016/05/stakes-are-high-oracle-v-google-public-has-already-lost-big <comment><USER2> Anyone who uses or is considering to use an Oracle product should pay attention to their litigation history

<comment><USER3> This raises an interesting question: Oracle licensing horror stories apart, how many times has Oracle actually sued a customer?

<comment><USER4> Ask the state of Oregon

</comment></comment></comment><comment><USER5> Oracle employees are only shooting themselves in the foot by continuing to work for them. Guys, it's a nice, healthy job market out there. Please consider.

</comment><comment><USER6> Can one write and have the court enforce a free software licence that discriminates against companies that impose API copyright on others like what Oracle is doing?

Something along the lines of:

You can use this software, freely distribute it yada yada as long as you do not "pull an Oracle".

<comment><USER7> I'm sure you could (though it would have to be tested in court), but I'm missing the point slightly because Oracle (/Sun) is the original creator of Java, so they would not be building it on top of your license (nor would any other "Oracle" with similar intentions).

If this style of licensing became so ubiquitous that essentially everyone in the future demanded it, then I guess it could make sense.

<comment><USER8> Imagine all GPL software required the licensee to never enforce API copyright, and if they ever enforced API copyright (over unrelated code), their license to the GPL code was null and void. Then Oracle can't run Linux.

</comment></comment></comment><comment><USER9> What I don't understand, is why other big tech organisations don't join Google on this (like Microsoft, Apple, Facebook, Red Hat, IBM, Intel, etc)? The result will obviously affect them, whether it is now or in the long run.

<comment><USER10> Microsoft actually argued in favor of Oracle.

</comment></comment><comment><USER11> Let's say Google loses this case. What are the implications for my free, open source software? And my closed source commercial software?

<comment><USER12> > What are the implications for my free, open source software? And my closed > source commercial software?

Software that implements other party's APIs might be obligated to agree to a licensing agreement - projects like Wine, Samba and various 3rd-party emulators. Ironically, Microsoft's discontinued, Android-compatible project Astoria would be exposed (to both Google _and_ Oracle) - Microsoft submitted an amicus in the first Oracle v Google case supporting Oracle's cause. I am not sure if Xamarin- and Cordova-/Phonegap-type projects would be subject to Apple's lawsuits.

I also suspect web-APIs might also become risky, making it possibly for Amazon to sue you for providing AWS-compatible APIs[1] for example

Disclamer: I am not a lawyer, this is just my layman's perspective.

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

<comment><USER10> > Software that implements other party's APIs might be obligated to agree to a > licensing agreement - projects like Wine, Samba and various 3rd-party > emulators.

It's far, far larger than that. Netscape implemented the Blink tag first and other browsers followed suit. Now Netscape (or whoever owns that copyright) can sue all browsers that implement the Blink tag.

</comment></comment></comment><comment><USER13> The court that decided that APIs were copy-writable was a federal patent circuit, their decision is not binding as precedent.

<comment><USER14> Is it binding in that circuit?

<comment><USER15> Which is a good point, that's a major circuit for tech.

Also, what happens if another circuit rules the opposite? Can we start a case in a circuit without incompetent judges?

Furthermore, if these judges are elected, they need to be VOTED OUT

<comment><USER16> The problem is the First Circuit gets ALL patent cases nationwide, so with this precedent in place anyone wanting to claim copyright infringement on a API will toss in a Patent claim as well to ensure it goes only to the First Circuit

With the high court refusing to address the issue, we will never see another court get one of these cases.

<comment><USER14> Yap, this is what I thought. The easy way to go to that court is tossing a patent claim

</comment></comment></comment></comment></comment><comment><USER17> erm...this is confusing...what is the EFF saying here?

It appears they don't want Google to use the fair use argument. Okay. But what else are they recommending?

<comment><USER18> That the last decision that API's are copyrighted is already the problem. Google - or anyone else - shouldn't have to need to use the fair use argument for this. This is already a law suit which shouldn't be necessary.

<comment><USER19> This idea that APIs are copyrighted in the US is a bigger problem beyond its borders. I don't know how familiar Americans are about how aggressively the US pushes its own legal interpretations of copyright law into other countries, but it is a continuing hassle.

The main problem here is that many countries _do not have fair use_! So if the legal interpretation that APIs are copyrighted spreads, it doesn't matter if it is fair use in the US. Even if countries specifically enact laws to exclude APIs from copyright law, you can bet that there will be huge pressure from the US to include it.

The Java trap after all -- only worse. We can't even reimplement it. We can't even implement to specs unless there is a license agreement (and we thought that patents were bad...)! I hate to be Chicken Little, but the sky does seem to be moving ominously quickly in the downward direction.

<comment><USER20> In some countries, like Brazil, softwares are not copyrighted, nor ideas. They are considered as "art", like a book, so you can't copy, use, etc., without authorization. But you can get the idea and rewrite it. You can't use the same buttons from some Microsoft product, but nothing stops you from deciding that a disk symbol means "save".

<comment><USER21> That sounds like copyright.

</comment></comment></comment></comment></comment><comment><USER22> It's simple, as a professional developer (that gets paid, more is better) I want companies to get paid for software and well.

When they don't, I'm not happy, so I hope Oracle wins. But Google will win, not because they are right. Oracle's lawyers are idiots as they can't show it's same. For example run apache http client jar on android and java. It's same. Idiots.

And would you want Google to violate GPL?

<comment><USER23> It's my understanding that the problem is not with source theft/copying in violation of licensing. It's with cloning an API.

If Oracle (or anyone) can copyright an API then we might as well pack up and go home. By that measure, you make a new JavaScript library for LeftPad and copyright the _API_ along with the source. Now people start using your library. But it's inefficient. So I come along and clone it, make it faster, better, stronger, the $6 million LeftPad-compatible clone. You can sue me for violating your API copyright.

Welcome to the end.

<comment><USER3> That is what Chicken Little would like you to believe, but you always have the option of devising your own API, call it prefixWithChars. If your implementation really is that much better, people will go through the effort of migrating their software.

The sky is not falling.

<comment><USER23> But it's not a compatible _API_. At that point, I have a second library and everyone has to rewrite their code to use it. This defeats one of the main benefits of having libraries in the first place.

The benefit of a library, fundamentally, is that any library with a compatible interface (described by the API) can be dropped in and used in place of another library without modification to the calling code. Cloning functionality is not the same thing if we have to put a prefix: thrawaykf05s_leftPad or Jtsummers_leftPad in front of everything.

In theory, as a developer using dynamically linked libraries, I can drop in _any_ version of a library without recompiling. As a user that means you can drop in AMD's OpenGL implementation or a GPL implementation or Nvidia's and see no difference in how you launch your program (though you'd see a difference in performance and perhaps behavior).

(OpenGL isn't a great example because the consortium running it won't do this, but it is a great example because there are many implementations.)

Now, as a developer you have to develop 100 code paths to handle each potential OpenGL implementation. Or maybe some nice person does that for you with a wrapper library. But now that wrapper library API is _also_ copyrighted and it's out of date. So _another_ API comes into existence that wraps it _AND_ adds new APIs to its backend. That'd be really fucking stupid.

<comment><USER3> As a consumer of APIs I agree that having drop-in replacements for APIs is the ideal state. However, as a producer of APIs, I also appreciate the efforts required to design a good API. There's some value in that. This translates to any product other than an API, of course, but in general if somebody creates something of value, I believe people who derive value from it should respect the creators' wishes.

This case is not, of course, about APIs. It's because Sun created this enormously valuable Java developer base, and Google totally free-loaded on that to bootstrap Android. The API just happens to be the means, and hence the crux of the lawsuit.</comment></comment></comment></comment></comment>


What if the TSA were held to the same standards as doctors? - <AUTHOR> http://www.schneier.com/blog/archives/2007/12/airport_securit_11.html <comment><USER2> Are there enough attempted terrorist attacks to demonstrate which techniques are and are not effective in stopping them? There are a lot of cancer patients to test potential remedies on, and for control groups, etc. What is the corresponding methodology for terrorist attacks?</comment>


Ask HN: What are physicists doing? - cool-RR

In this thread I would like to consult with you, HN readers, about a problem I have with physics. It is a sort of gap between the way I research physics, and the way mainstream physicists do it. This thread will probably appeal only to those of you who are interested/knowledgeable in physics.
A little introduction about myself is necessary. I'm 22 years old. I live in Israel. My main occupation right now is studying physics. However, I am not a student in a university, nor am I affiliated with any other kind of academic institution. It's been about a year and a half since I've started studying physics in this independent way. I used to be an official student, a few years ago. I was an undergrad in Electric Engineering. I quit there after one year. Then I decided to start studying math independently. I did that for about a year and a half. Then I stopped with math and decided to start studying physics, with the goal of figuring out how the universe works.
So I'm about a year and a half into my quest. I can say that up to now I studied Special Relativity and Classic Electromagnetism.
The thing is, I feel that I have diverted from the ways of academic physicists. Actually, after these 1.5 years it has come to a point where I feel like I'm speaking a different language than the one they're speaking. Perhaps I took a wrong turn somewhere and I'm heading into a dead end? Perhaps the mainstream physicists took a wrong turn and I'm taking the right one? Or maybe some other possibility? I am hoping that you, HN readers, will be able to shed some light on this gap.
What are these differences between me and them? It will take some exposition before I could explain. Some of the things I say about physics may seem wrong or provocative to you. If you feel the urge to tell me I'm wrong, please do it with a thorough, logical argument. If anything seems unclear, please ask. Here we go:
In Newtonian mechanics, life was simple. There was a collection of bodies in different places. Each pair of them exerted forces on each other. There were rules that said exactly how much force they exerted. With these rules it was possible to calculate exactly what the force on each body was. After you knew the force for a body, you could know the acceleration that that body would have, according to the revered formula, F=m a, or in its more useful form, a=F/m. After you knew the acceleration, you could advance the simulation by a small time-step. The bodies would then move a bit, and you would calculate the forces again, and so on.
If you took a small enough time-step, you could calculate the outcome of any physical system to any desired accuracy. All the subjects taught in Newtonian mechanics, such as angular momentum, centrifugal forces, conservative fields, and kinetic and potential energies would appear as emergent phenomena from these rules. They were just epiphenomena to the true axioms of physics: The force equations and F=m a.
That was Newtonian mechanics. In approaching Special Relativity, I expected the same style, maybe a bit more complicated. Eventually that's what I got, but it was hard work, and I had to build big parts of the system myself, with only hints from physics textbooks (more about that later.) It turns out that Special Relativity is just a tad more complicated than the above description of Newtonian mechanics. Instead of the formula a = F/m, there is a more complicated formula:
a = (F- v (F v)/c^2)/(m gamma)
(Where v is the velocity, gamma is some function of the velocity, c is the speed of light and that (F v) is a dot product.)
And the formulas for calculating forces become more complicated as well. I will not list them here, since the mathtext will become too cumbersome, but if anyone will insist I'll post them. These equations are eventually what is called Classic Electromagnetism. All the revered Maxwell equations turn out to be just special cases of these equations.
(Also, in Special Relativity there is the issue of Lorentz transformations: but that is important only if you want to change viewpoints, and even then it can be deduced from the rules above.)
Another note: I know that the system I described is not an end-all model of the world. It does not include Quantum Mechanics, and thus it will be valid only for macroscopic bodies. (It also does not include General Relativity, and thus it could not deal with gravitation, but that is less important in my opinion.)
I mentioned that I had to build most of that system myself, and that physics textbooks don't give this system explicitly. That is the biggest gap between the physics community and myself. Physicists do not seem to accept this system. The equation for the acceleration that I supplied above cannot be found in any textbook, or at least I didn't find it. That is even though it can be easily derived from known equations of Special Relativity. The equation for the Electromagnetic force is almost as hard-to-find, although it can be derived from the well-known Liénard-Wiechert potentials. Why are these things not mentioned in textbooks? Am I blind to something? What are physicists doing, how can they research anything without knowing this system?
About Quantum Mechanics: Even though the system I described will break down at the quantum level, I think it's indispensable for trying to figure out how the quantum world works. It is true that as you go smaller and smaller, the physical reality will deviate from this macroscopic model; But if you want to study and understand these deviations, you should understand the macroscopic model first, so you will know exactly what to compare the physical reality against!
That's my opinion. I may be wrong, and if I am, I would love to hear a well-reasoned rebuttal. I really hope you guys can shed some light on this.
Ram. <comment><AUTHOR> You say "physics textbooks don't give this system explicitly". They don't need to - they simply present the system that's most instructive to learn or is most interesting to their authors. As long as your formula or "system" is consistent with the accepted formulations of special relativity, you have no reason to worry.

PS - Most physics communities are getting by with their own methods, and if you really think yours adds something you should write a textbook (or a paper).

<comment> cool-RR I understand that their systems may be simpler for their uses, and it's possible that for this reason they use Maxwell's equations and things like that: But how can they not mention it, even once? I would personally expect these equations to be revered in every Classic Electromagnetism book. Okay, so they are not revered, maybe my taste is a little peculiar, but they are not even mentioned! I just can't understand it. Think how much Maxwell's laws are revered, and this is one formula that contains them all and more, in one line. Don't you think that they would mention it?

That's what's baffling me. Do they not know this? Do they not care? How can they not care?

About your PS: Yes, I'm working on writing this.

</comment></comment><comment><USER2> So... Special relativity is called "special" because it specifically assumes _no acceleration_ and therefore, no force. That formula you have is an approximation for "small" forces. General relativity is what actually explains space with acceleration (using Riemann Geometry, another fascination and extremely complex topic in of itself relying on tensor calculus, which is _another_ fascinating and extremely complex topic in of itself). Secondly, the Lorentz transformation is _critical_ to special relativity, because that is what gave rise to the entire theory and also because the Lorentz transformation is exact (up to QM effects and 0 acceleration). Also, the Lorentz transform is sufficient to derive the result e = mc^2 among many other useful results on momentum and particle collisions (or at least the aftereffects thereof, since we can have no forces) which is why special relativity is even taught in isolation.

As to the textbooks, all I can say is that you haven't come by the right textbooks yet. I would advise reading the Feynman's lectures on physics (all 3 volumes). Expensive but worth it and if you want, you could probably find free pdfs online. FLs does indeed go into the gory details of special relativity (v1 I think) and even shows how to derive most of the useful results including (I think) information on how to derive the Lorentz transformation from the Special Relativity's base assumption: the speed of light is constant in all time frames. ENM along with several applications is also discussed in FLs (v2 I think). FLs V3 covers QM is great detail (well... the parts that we humans can solve mostly). Another very good book on ENM would be Electricity and Magnetism by Purcell, Berkley Physics Course Vol. 2.

Oh btw. the central assumption of General Relativity is that force and gravity are just 2 different manifestations of the same phenomenon. Thus, for very weak gravitational fields, you could actually use the formula you have. Just that it would not be very useful because a) you would have to interpret it as constantly changing time frames over small time intervals, and b) because I don't think the Earth's gravitational field (or the moon's) is weak enough to justify the approximations inherent in your equation.

A note on finding good textbooks: Pick a good university. Any good university (I would advise Caltech but thats because thats where I study) and chances are _very_ good that said universities will publish the course textbooks for their classes. Some will even publish the homework assignments and solution sets along with lecture notes. Eg. <http://www.pma.caltech.edu/GSR/physicscourses.html> is the place where CIT has currently placed a convenient listing of all the physics courses offered with links to their web pages which contain among other things: the textbooks, syllabus, and in most cases, the homeworks for the class. Finding textbooks from there shouldn't be very difficult.

<comment> cool-RR There are many objections I have to raise to your post. But let's just look at the first thing you say.

You say that SR can't handle acceleration. I disagree. Let's examine this issue.

My first question about it is: Assume you have a "twin paradox" situation. One twin stays on earth for a year, while the other twin goes somewhere far away in space and returns, in relatvistic speed. The travelling twin accelerates smoothly in his journey. Given the twin's trajectory, the mission is to calculate in how many years he has grown old. Do you think that SR can't handle this case?

Second question. Observe the Lienard-Wiechert potentials. They say the exact value of the EM field at any given point. What is the significance of the value of the field E, if not the chrage of the body times the force that acts on it? If it does mean that, then "force" in which context, if not SR? Newtonian? GR?

<comment><USER2> The twin paradox cannot be handled by SR. The difference in aging comes about due to time dialation caused by the differential acceleration that the twins experience (the twin in the spaceship is accelerated and the other is not). SR can be used to judge the middl period after the acceleration but it will not give any useful information because you can always switch viewpoints. If you have two bodies moving at some relative velocities, _both_ can claim that the other is moving slowly in time. The mathematics of communication and speed of light work out so that this system is consistent. The difference in measured time comes from the acceleration that one of the bodies must undergo to enter the same time frame as the other.

Secondly, electric fields have intrinsic effects as in EM radiation (colloquially known as light) and need not apply any force to have effects. The movement of emitters of electrical fields through space and acceleration thereof actually give rise to magnetic fields. Read Berkley Phys. Vol. 2 ch. 5 which shows how this happens in the framework of SR. It later hints how tensors can be used to generalize this result to GR. So... in response to your question, if force is applied, either it must be approximated in a Newtonian or SR context, or GR must be used in its full generality. Usually, the forces and particles involved are sufficiently small that approximations work (see success of Newtonian mechanics), but that is not the general case. Also, very common is the tendency to derive general results and then use them is special cases. Maxwell's equations are an excellent example. They refer only to EM fields and are exact (uptil QM of course).

<comment> cool-RR Okay Newt, now we have something we can compare! Because I claim that SR _can_ handle such a case. I propose that I will give the answer as I calculate it from my version of SR, and you can give it from GR or whatever you think is necessary. Does that seem like a worthwhile comparison to you? Let's say that our travelling twin takes a trip of one second (not one year, to make the calculation easier). Let's say he goes in the following trajectory: x(t)=0.9 c sin (k t) /k Where k equals (pi/second). How older will the twin be after the journey? I got the result of 0.7459255 seconds. What is yours?

<comment><USER2> There is a problem with your analysis. Switch viewpoints to the reference frame of the traveling twin. In that case, that twin stays in a constant position and the other twin travels with a trajectory of x(t) = -0.9 c sin(kt) / k. The negative sign is irrelevant as we are only interested in absolute velocity and the negative sign implies that the movement is in the opposite directions. Then by your calculations, the other twin should now experience 0.74... seconds. Ie. Without accounting for the acceleration that one of the twins experiences, you can always switch frames and therefore cannot draw any conclusive results for both twins simultaneously unless you fix the reference frame (but in that case, differential aging really makes very little sense).

As to calculation the actual difference in age, I don't know GR sufficiently well to be able to calculate the aging of the twins but I know some people who do. I have contacted them and will get back to you once they send me an answer.

<comment> cool-RR Hello Newt,

Thanks for answering and for forwarding this to people who know GR, this might really help me.

Regarding your first paragraph: I didn't give you my analysis, I only gave you a final answer, so how can you say there's a problem with my analysis? It's more like, there's a problem with your guess of what my analysis was. I phrased the original question accurately and gave a final answer.

The contradiction you're talking about does happen if you try to switch reference frames without taking note of the acceleration. I didn't try to switch reference frames.

<comment><USER2> That is the problem. One of the central tenants of relativity is that what reference frames we choose is irrelevant as long as we account for all the relativistic effects. In you analysis, whatever that may be, you have two twins which separate, move around, and then return to the same reference frame and your result is apparently dependent on which twin's reference frame you are using. That is a contradiction. Thus the need to account for the acceleration that one of the twins experiences w.r.t. the rest of the universe.

<comment> cool-RR We are having quite a funny argument, because it seems we both see the problem.

"One of the central tenants of relativity is that what reference frames we choose is irrelevant as long as we account for all the relativistic effects."

I think that applies only to _inertial_ frames. At least in my version of SR that is so.

"your result is apparently dependent on which twin's reference frame you are using. That is a contradiction."

I know it is dependent. I don't see what's the contradiction. The earth twin has a special status - he is non-accelerating. His reference frame is therefore inertial. The other twin _is_ accelerating. His reference frame is non-inertial.

Where is the problem here?</comment></comment></comment></comment></comment></comment></comment></comment>


PayPal Brings Allowances Into the 21st Century - <AUTHOR> http://bits.blogs.nytimes.com/2008/12/01/paypal-brings-the-weekly-allowance-into-the-21st-century/ <comment><USER2> Are allowances even a good idea in the first place? My parents never gave me an allowance. I did chores, and I was compensated for my work. It gave me a deep understanding of work, and it was simple to go from "working" for my parents to working for other people. What does an allowance teach children?

<comment><USER3> My parents almost never gave me any money directly. My dad did teach me to sell though. From 12-16 I made some of my money selling misc things at flea markets and the like on weekends.

Probably some of the most valuable entrepreneurial learning I ever got was standing in front of a booth trying to convince people walking around to come over and buy something.

I probably had a half dozen "businesses" with different friends and family before I was 18. Much better than an allowance.

<comment><USER4> Same for me. I asked my Dad for an allowance once. He laughed and said, "You're barely earning your keep the way it is!" Then he sent me back to work. The end.

</comment></comment></comment><comment><USER5> this is actually pretty brilliant on eBay's part, since it'll get the kids to only buy on eBay, since thats pretty much the only place where buyers accept paypal(yes others accept paypal too, but on eBay pretty much everyone does).

So it'll generate them fees from sales, and they'll condition the kids to buy their stuff on eBay instead of other sites.

<comment><USER6> Paypal also has a browser plugin which will generate a one-time Visa card number, for use on sites which don't accept Paypal.

I hear there are some sites on the Internet which take Visa.

This instantly solves a pressing issue for many 13 year olds, namely, how do I pay for my WoW account? And now Ebay will happily take, hmm, about fifty cents of every month's bill. Oh, want to order from Amazon? You can do that, too. iTunes? You can do that, too.

And when you get to 18 and can finally get a real honest-to-God debit card... why bother? You know how to do things via Paypal.

I think this is _brilliant_. (Note: no financial interest in eBay, aside from moving five figures through Paypal this year.)</comment></comment>


Ask HN: Any recommendations for business insurance in CA for SaaS companies? - <AUTHOR>

Does YC have a recommended insurance list they can share with the community? <comment><USER2> What kind of insurance are you looking for? (Not saying I have any suggestions. Just that this info might get some response.)</comment>


A Deep Hierarchical Approach to Lifelong Learning in Minecraft - <AUTHOR> https://arxiv.org/abs/1604.07255 <comment><USER2> And sadly, another paper about software with no source code whatsoever.

<comment><USER3> Email them politely asking for the code.

<comment><USER2> Doesn't scale usefully nor temporally.

<comment><USER3> It scales better than complaining on Hacker News.

<comment><USER2> It does effectively warn the readership and saves them from having to trawl the document and the web on their own for the source.

</comment></comment></comment></comment></comment><comment><AUTHOR> Some discussion: [https://discuss.openai.com/t/research-a-deep-hierarchical- ap...](https://discuss.openai.com/t/research-a-deep-hierarchical-approach-to- lifelong-learning-in-minecraft-aaai-17/508/3)

</comment><comment><USER4> This looks like a really cool architecture, but I'm mildly uncertain about how well it scales given the simplicity of the tasks demonstrated. Delivery tasks are the most basic tasks in RL research. I'd be interested in predator/hazard avoidance, as well as some sort of rudimentary reasoning (might require analogy structure built-in?).

Additionally, the pure-pixel input is neato, but the discrete outputs seem limiting.

That being said, I'm overall very happy with the direction of research!</comment>