'Metal-Eating' Plant Capable of Absorbing 18,000 PPM of Nickel - <AUTHOR> http://www.autoworldnews.com/articles/7384/20140512/metal-eatiing-plant-capable-of-absorbing-18-000-ppm-of-nickle.htm

<comment><USER2> What is not really pointed out is that you can't just plant these on polluted ground and have it magically cleaned up. You have to periodically harvest the plants, otherwise when they die they'll decompose and the metals go back into the soil.

The harvested plant material would then essentially be toxic waste which will have to be specially landfilled, or if valuable, processed to extract the raw metals absorbed.

Also not sure how deep their roots go but probably only a few inches of topsoil could be cleaned up in this way.

<comment><AUTHOR> From the article:

"Once the plant absorbs a significant amount of metal, they can also be harvested for their commercially valuable contents, according to the release."

"nickel, zinc, copper and manganese in high concentrations" are all commercially viable metals worth collecting, assuming the extraction process is cheaper than digging it out of the ground.

I haven't been able to find out how long the roots are, or how deep they typically grow

<comment><USER3> Considering the family (Violaceae), I'd guess pretty shallow (<30cm).

</comment></comment></comment><comment><USER4> Wonder if this is a step towards Freeman Dyson's carbon-dense tree that solves the carbon emissions issue.

</comment><comment><USER5> I wonder how this plant compares to Sebertia acuminata from New Caledonia: [http://books.google.com/books?id=BCQ49kJG8hgC&lpg=PA46&ots=N...](http://books.google.com/books?id=BCQ49kJG8hgC&lpg=PA46&ots=Nlk_3VAS_K&dq=new%20caledonia%20nickel%20tree&pg=PA44#v=onepage&q=new%20caledonia%20nickel%20tree&f=false)

<comment><AUTHOR> fascinating! thanks for sharing link - plan to read when I have time later

</comment></comment><comment><USER6> Article claims that this find can advance a lot of fields. However, besides increase of knowledge in biochemical field, what other advantages would studying it confer?

<comment><USER7> With some genetic engineering I wonder if this could be used to clean arsenic or lead from a field.

Too bad it wouldn't work for gold.

<comment><USER8> Drop some seeds in (e.g.) Fort Knox and watch the gold disappear?

<comment><USER9> I look forward to near-future fields of fiber-optic-eating plants sown over Internet trunk lines that can use MITM attacks to subvert the Bitcoin blockchain, and store the stolen coins in SSD fruits that grow an organic USB port for later harvesting.

<comment><USER10> Reading this, I totally expected it to be featured in a future episode of Almost Human ... and then I remembered it was canceled and I had a sad :(

</comment></comment></comment></comment></comment><comment><USER11> Holy crap that autoplay video is annoying. I'd never before seen a video widget that only lets you pause for about five seconds before it AUTOMATICALLY UNPAUSES ITSELF. Please tell me this is not the future.</comment>


Show HN: Listen to HN on the go in a radio format - <AUTHOR> http://hackerwave.com <comment><USER2> This is terrific! I listened to it for about a half hour last night, and it was far more useful than I thought! One of the articles I had read earlier in the day, and your parser did a great job of using different voices for different people quoted in the article, which made the article flow in a way that's pretty close to real speech.

One of the articles, however, seemed to switch from voice to voice for no discerning reason. It might have been a medium article, where authors are more likely to stylize the text with bold, underline, italics, etc. That made it a bit confusing and difficult to follow.

For me, listening to any spoken word requires a little mental effort. For example, listening to an NPR podcast takes about 10%. Your app maybe took 20%. That's within a margin that, if you're able to smooth out your speech algorithms and tune the voice-choice algorithm, I could imagine this being as easy to listen to as a podcast.

So, on the whole, the voice-choice algorithm needs a little work, but other than that, I really like this!

</comment><comment><USER3> Wow, thank you for creating this. I hope in the future the Android version will be available.

</comment><comment><USER4> Wow, that's exactly what I was searching for two weeks ago. Android version would be nice too.

</comment><comment><USER5> Once we achieve This American Life style producing, we're golden.

</comment><comment><USER6> stuff like this is pretty rad.

Always wanting to convert articles instantaneously into podcasts because they make a commute easier.

Curious about copyright but ¯\\_(ツ)_/¯

<comment><USER7> And how would it pronounce ¯\\_(ツ)_/¯?

<comment><USER8> macron backslash low line left parenthesis tsu right parenthesis low line slash macron

<comment><USER9> wow even though I know katakana, I never put it together that the shruggie used tsu. I'm gonna start using the shi version ¯\\_(シ)_/¯</comment></comment></comment></comment>


Google to put buttons on backs of Android devices - <AUTHOR> http://vator.tv/news/2013-03-09-google-patent-wants-to-put-all-of-your-fingers-to-use

<comment><USER2> Apple filed for a similar patent and I wrote about it in 2007: [https://mikecane.wordpress.com/2007/05/10/oy-apple- backsided...](https://mikecane.wordpress.com/2007/05/10/oy-apple-backsided- ipod-idea-gives-me-sony-clie-creeps/)</comment>


Why We Should Let the Pantheon Crack - <AUTHOR> http://nautil.us/issue/24/error/why-we-should-let-the-pantheon-crack <comment><USER2> Actually is worth a read. A couple of choice quotes:

"There's no greater definition of success for a building than it's been standing for 20 centuries."

It's basically a discussion of understanding (or not) old systems, patching old implementations,and how the quest for the new _can_ (doesn't have to) lead you astray.

<comment><USER3> An analogy would be to notice that a COBOL mainframe app wasn't RESTful, and building a VM and dependency injection framework for COBOL that would make up for this lack (rather than sandboxing the app in an environment that could have RESTful interfaces it's boundaries).

</comment></comment><comment><USER3> Missing from the article is any discussion of survivorship bias.

At least some of the resilience of these monuments is due to the fact that we are only studying the extant examples, which simply haven't collapsed, and so, tautologically, exhibit positive qualities that prevent (or avoid) collapse.

This isn't random, of course, so the longer a building has survived the longer it is likely to continue surviving.

We don't see around us the many buildings, built using the very same principles, that did collapse.

Certainly there is much to be learned by studying the survivors, but giving all of the credit to the skill of the designers and the principles they used seems like an attribution error.</comment>


Welcome to the new web. - <AUTHOR> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033914.html

<comment><USER2> I agree with the claim in this forum post. It is annoying to have all pages javascript generated, clicks hijacked to make some special sauce, and content popping in, up, down or out whenever you hover something. It is a growing mess that will have it "let's rollback and clean this crap out" time, like Google did with its famous blank home page.

Another example: trello.com is a very nice and free card tool for small projects, but because they wanted to avoid having an "edit" button on editable text, they hijack my clicks, so it makes it painful to select text, and quite impossible to use "middle-click as paste".

But, there is a more positive perspective liked to Google+. In fact, I think the midterm result of Google entering in the SNS arena could (and should) be to force open Facebook. I mean, right now G+ is not open, it doesn't have all the needed APIs, and this is probably OK because they they need a critical mass before opening, and one should not bash them for testing, pondering, adjusting a bit more before releasing some important changes. Time is on their side anyway.

But in the end, they will go, I hope, the full good-old Google way, which means:

\- Read/write APIs for posts, followers, followees, etc.

\- Ability to dump all data and go away

\- RSS or similar subscribing hooks

These tools will allow a much higher interoperability for social content, similar to interoperability of emails today. Users will not really care if the comments on their baby pics are written using Facebook, G+ or any other Social Content Manager, they will read and respond to them in the SNS of their choice, like we do today with emails. (I wrote a bit more ion this topic there: [https://plus.google.com/104035200377885758362/posts/A9r7twSD...](https://plus.google.com/104035200377885758362/posts/A9r7twSD5Yh))

<comment><USER3> You're an optimist.

I'm a pessimist - Google+ is too little, too late. Facebook is already too big to fail, Google+ being here the equivalent of Microsoft's Bing.

Facebook won't open up. They don't have than in their DNA, their biggest asset is their huge audience and they'll do anything they can to keep that audience on Facebook -- opening up their platform in a way that benefits competitors simply makes no sense.

The Internet as we know it is indeed dying.

<comment><USER4> There is no "too big to fail". There was a little financial incident in a small north american country some time ago, where some "too big to fail" institutions failed. I've already heared some teens don't like Facebook anymore because mom and dad are also there.

What changes is the web framework style. Asynchronous page loading provides a smoother experience compared to refreshing the whole page. Gmail and Thunderbird will be increasingly similar. Just that one is in a sandbox called browser and the other's sandbox is called operation system.

<comment><USER3> Indeed, there is no such thing as _too big to fail_ , however you can say of certain companies that they are _too big to fail easily_. Facebook was once small and fragile. Not anymore.

         What changes is the web framework style

The changes are a lot deeper than that. The web is increasingly against sharing, against cooperation, against standards.

The _semantic web_ dream is dying, replaced by web versions of Microsoft Exchange.

<comment><USER2> > web versions of Microsoft Exchange.

What a nightmare! Hey guys, we are we so pessimistic these times? We should fight instead.

\- Facebook is annoying but you want to keep in touch? Use one of the many tools allowing you to receive your fiends baby pics without opening Facebook. If no tool suits you, hack another one! (I would love a command line fb, by the way)

\- Tired of shitty web apps that lost the pure HTTP way and mess with click events? Find or hack an extension that shut them down. If too badly bad, pull on the black hat and make a fuck of that.

\- Lack of inspiration? Read again pg's essays, it fuels one with renewed inspiration.

<comment><USER5> I don't think the problem most people have with Facebook is the interface, but the lack of control over your personal data.

</comment></comment></comment></comment></comment></comment><comment><USER6> As I write this there are two comments that have been downvoted to the bottom for expressing how difficult the post is to read. They draw attention to the post's textual interface, albeit perhaps sarcastically ("Is the new web better at UX than this? That was painful to look at.").

Not only is theirs a serious concern, but it speaks to the main issue of the post, for it reminds us that like web interfaces, even text has accreted arbitrary rules to interpret it. Take the apostrophe for example, it is for most purposes superflous as one can tell from context whether a word is plural, possessive or a contraction. Well, I can tell the difference, cant you?

The original post is saturated with consistent, but by no means universal and certainly not empirically-derived, pre-conceived rules for communicating textual content: the date posted is in italics; the site name is bracketed and bold; the post name is bold; links which serve a sorting function are colored, underlined and bracketed; a presumably copied email prefaces the actual post in italics with each line itself prefaced with a less-than-sign; and most importantly much of the post is composed of incomplete sentences ("A web where...").

We allow ourselves to bend the rules of grammar. And as we bend them, we adapt to the new general rule.

We are all familiar with the english teacher's common correction of a misplaced object: "It's 'He and I went to the store', not 'Me and him went to the store'". This "rule" has been so often repeated, that most days I hear college-educated individuals perform the inverse, substituting the nominative for the objective case, as in "Bob critiqued the web page with Jack and I." What is interesting to me is apparently the act of replacing the nominative with the objective also occured in the Latin language around 200 AD (and it's a common act in children). So, if we create our rules for grammar empirically and not not arbitrarily, we can look at saying "Me and Jack did something" as acceptable because it has a natural precedent.

Which is all just to say that communication as a web form or in paragraphs is subjective and organic. Differences in type should be no more surprising than differences in human ethnicity.

<comment><USER7> Perhaps not coincidentally, 200 AD was about the time that Rome started to falter: in 235, the "Crisis of the Third Century" permanently wrecked trade, knowledge, and culture. The crisis marked the real beginning of the medieval period, and 476 was too late to do anything about it.

<comment><USER6> Tis true. And if not merely coincidence, it leaves us our choice of interpretation: was it cause or consequence.

</comment></comment></comment><comment><USER8> Listen to this guy. Nils Dagsson Moskopp, what a great post.

We are giving the web away because people can't handle email, address book and a blog.

<comment><USER9> > _"We are giving the web away because people can't handle email, address book > and a blog."_

How typically computer-geek of you. Users don't like our convoluted, hard-to- use systems and have abandoned them for products that are easier to use and appeal more to their perception of how technology should work!

How dare they! The plebes! DO NOT THEY NOT KNOW WHAT THEY DO?!

Why won't people _do more work_ to preserve the freedom of the web, like setting up their own blogs, and manually maintaining their own contacts?!

<comment><USER3> That's because of a lack of education, because we, the technically inclined people, have failed to serve the normal people, preferring instead to:

1) reinvent the wheel over and over, each time with a new interface, shinier and more limited than the one before it

2) cater more to our hypothetical grandmas instead of our children ... which ironically are able to write HTML in Notepad just fine, if taught how to do that

         Users don't like our convoluted, hard-to-use
         systems and have abandoned them for products
         that are easier to use

What you're missing here is that those products _that are easier to use_ get replaced like socks, with the users being back on square 1 every single time and struggling to perform even the most basic tasks by clicking their way around.

People all over Europe have learned to drive cars with manual transmissions - because after the initial pain, the vegetative nervous system kicks in and the wheel, the pedals, the gear switch, all of them become a natural extension, of which you don't think about anymore, _just like breathing_. And if automatic transmissions are great too, that's because they stay out of your way.

The UI of modern software is nothing like that. Nothing is logical anymore, nothing is designed anymore to be an extension of you. Normal users have to think about their every action, they have to visually search for clues in the UI for every stupid thing they do, they have to rote learn the paths they have to take for the software to take them from some point A, to some other point B. I saw users that have notes on the actual clicks they have to make for certain common actions. I don't know about you, but to me this is freaking painful to watch ;)

Btw, for some good user-experience guidelines, check out The Design of Everyday Things: <http://amzn.to/ryfiuI> (the link does contain my affiliate code) ... the one thing I took away from this book is that _simplicity_ is a complex topic.

         Why won't people do more work ...
         setting up their own blogs

Setting up your own blog is just a few clicks away on Google's Blogger, on Wordpress.com, on Tumblr.com or on countless other services. It takes more work to set up a template that represents your style, but that's not something you can do on Facebook anyway.

Really, step down from your high horse, it's not like you yourself are not guilty for the current state of our industry. We all are.

<comment><USER10> "People all over Europe have learned to drive cars with manual transmissions - because after the initial pain, the vegetative nervous system kicks in and the wheel, the pedals, the gear switch, all of them become a natural extension, of which you don't think about anymore, just like breathing. And if automatic transmissions are great too, that's because they stay out of your way."

This is how it is, every time a user gets familiar with _concepts_ of his/her user interface, such as a minimize button, a window, a taskbar, it is "re- invented" and changed. No longer is there a minimize button in latest Ubuntu, the taskbar is no longer a taskbar its some weird form of activity with grouping bar in Windows 7.

All the concepts of the user interface such as buttons and scrollbars are exchanged, the basis of what a user _interfaces_ with, is changed. A great suprise then when a user has to relearn everything and gain new concepts just to use a new tool or web a new website. Many just dont go down that way and stick it out with facebook as "the internet".

Tip for UI designers: Stop designing, stop your user-interfacing design, there is one already which the user knows. Focus on _your_ data and fit it into the old and tried concepts of buttons that look like buttons and have only one function, not also state "button is staying pressed in", thats a checkbox. Darn it.

<comment><USER11> Unfortunately it's not possible to "stop" designing web UI as there is no standarzied ui library in html/css. Web apps have been shoehorned into a system that was never intended to behave like an app.

Stopping random UI experiments would require a replacement system designed specifically for web apps that access a standard library of controls.

<comment><USER12> We've been using Twitter's Bootstrap in quite a lot of our recent web app projects. It provides a reasonable "standard widget set": <http://twitter.github.com/bootstrap/>

<comment><USER11> Yeah there's lots of great UI libraries but it doesn't really solve the problem since they aren't universally applied.

Users still have to learn the UI controls of each library or whatever else the designers come up with.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> It's ironic that ten years ago many people (average consumers) thought that AOL was the Internet. Now they think Facebook and Google are. Ten years from now, it'll be something else and HN type people will still be doing their own thing as usual.

<comment><USER14> Is our thing complaining about the popular things from the lesser travelled discussion forums? Snickering about how the masses don't know Facebook from the web from the Internet. "The fools!"

That's obviously tongue in cheek but there's some truth to it. At the end of the day does it really matter if people are happy using the one thing on their computer that they can actually use and understand?

</comment></comment><comment><USER15> As much as I wish the innovations of g+ and Facebook were centered around RSS and email, this is just the way new technologies evolve. Identity management and permissions management for who can see a user's content just don't have a good standard yet. Therefore private companies are rolling their own proprietary solutions and competing with each other.

At some point, the standard techniques for dealing with these issues will become Standards. This is a well worn path. Html was a standardization of the previous 10 years of work on markup languages, plenty of them proprietary. There are other examples... ODF standardizing on XML and cloning established MS Office functionality... etc.

Real Standards that could address the article's concerns are only reasonable when NO innovation is necessary, merely choosing a methodology that has already been built and proven to work in practice. IMO, Java more or less committed suicide when it started a standards-first innovation process, which resulted in many multi-year projects doing design-by-committee of an api before anyone tried to build an implementation or an actual product on top of it.

As long as G+ is introducing features not available elsewhere, the fact that it's a currently closed system just isn't a reasonable criticism.

<comment><USER3> Out of curiosity, what features does G+ have that aren't available elsewhere.

</comment></comment><comment><USER16> Sounds just like the old web, if you were blind and went to a Flash fullscreen website.

As much as I like the ways that sites like G+ are trying to push the envelope, if you're handling data that was created by or belongs to others it's more important to fit into the greater data ecosystem than to stand out...

</comment><comment><USER17> To me the difference between "old-web" and "new-web" is a lot like the one between "program" and "application.

Old-web was just text and markup. A lot like the output of command line programs that could then be used by other programs to perform what we want.

New-web is about application. Programs made for the end-user. Apps aren't thought to be pipelined with other apps. Thus for a web-app, the browser is often designed to be the only supported plateform. Thus the extensive use of JS.

<comment><USER10> Straw man, text and markup was made for the end-user as well.

<comment><USER17> my point is that programs can be pipelined, not applications.

<comment><USER10> an application is a program. you're thinking of commands, which are a subset of programs

</comment></comment></comment></comment><comment><USER18> > _A web you cannot easily read without JavaScript because somewhere in the > page header there is a " <style> body { visibility: hidden; } </style>" > later getting unset by a script that the platform owners want you to run._

To be fair to Google, that sounds like a fairly standard clickjacking prevention mechanism. It's necessary to provide protection to browsers that don't support X-Frame-Options.

</comment><comment><USER19> The only power the "new web" has is the power we give it.

<comment><USER20> It's not us geeks that will decide this. It's people who never understood the things he's talking about, and therefore won't miss them much. The things he's talking about are all more complicated than the thugs replacing them for the common use case (though it makes many more complex things impossible), which makes this somewhat inevitable.

Tools will come out to ameliorate the problems with the new order of things. That things are controlled by a handful of entities is much more worrying, though.

</comment></comment><comment><USER21> i remember the old web, a web without RSS or ATOM feeds.

<comment><USER22> Yeah. Gopher and Archie. And you would 'talk' with someone. People had shell accounts.

Good thing is: No one is keeping you from giving a CPR to Fidonet. Redundancy gives resilience.

</comment></comment><comment><USER23> We need a better, open, ways of connecting people on the 'old' web.

</comment><comment><USER24> In the grant scheme of thing, do people really think it is a big deal if a page shows you a 404 error, even if the content you are looking for actually exists? I think it's very tempting to get lost in tiny details like that.

<comment><USER22> It might appear to some like a tiny detail, but things like this break the web. HTTP status codes are there for a good reason. A similar situation is when your provider redirects you to its own search page instead of giving you the 404.

</comment></comment><comment><USER25> So what are we going to do about it? There must be a business opportunity here.

<comment><USER22> I really don't get it, why the dying social networks like Myspace, Friendster, StudieVZ et.al. are not embracing the distributed social protocols like crazy.

OAuth, Salmon, PubSubHubbub, FOAF, ... everything is right there.

</comment></comment><comment><USER26> it's a bit sad that in the most decentralized media, people tend to stick to the most centralized utilities to communicate with each other (I use them too). but:

> With less sarcasm: What use is this if one already reads the blog?

none. if you don't want to use it - don't. move on.

giving users another subscription channel is not a problem. a problem appears when someone uses these closed platforms as their _only_ communication channel, f.ex. it's impossible to move a fanpage with it's community out of facebook. when people and organization treat it just as another feed broadcast (as whatwg did), everything is fine.

</comment><comment><USER27> I feel your pain; and wrote about it: [http://danielmillsap.com/blog/culture/cultural-artifacts- in-...](http://danielmillsap.com/blog/culture/cultural-artifacts-in-an- impermanent-digital-world/)

</comment><comment><USER28> And don't forget: "This content not authorized for mobile devices."

</comment><comment><USER29> The correct response to hyperbole is always, "We'll see."

<http://www.youtube.com/watch?v=Tbsx_vZTcNI>

</comment><comment><USER30> Google tried it the other way via Google Wave and unfortunately nobody bought into it.

<comment><USER31> Regarding the rendering technologies it was exactly the same, a big pile of JS that you need to render actual content.

The main point of the author seems to be that G+ doesn't use progressive enhancement.

</comment></comment><comment><USER32> I'm a member of a forum for graduates of one of the schools I went to. In 2007 it was a vibrant and active forum, growing steadily, and straining its hosting account, which constantly had to be expanded.

At some point, around 2009, most of the members of this forum got Facebook accounts. That forum is now completely dead.

Facebook took all the oxygen out of the site, and it seems like a lot of other sites.

Now very mainstream people seem to think of Facebook as "the internet" and they just hang out there. Some of the bigger sites are doing ok, still, of course.

But at least for that forum, its audience is gone.

To a person, the members of the audience say they love it, and many of them say they hate facebook because "its so impersonal." On the forum they were able to share more private things with closer friends.

I think they would rather hang out on the forum, but there isn't the critical mass anymore... simply because Facebook is more addictive.

It has gotten into some sort of a gamification, or addiction loop, in these peoples heads, it seems.

I think the web is going to undergo a radical change in the next 5 or so years.

<comment><USER33> As an administrator of an online message board, I concur. Web content is being so efficiently aggregated that some forums turn into the awkward conversation between two redditors: "Check this out!" "Heh, yeah. I saw that."

Communities before were usually separated by _platforms_ , because the platforms were not yet sophisticated enough to support vast communities of varying opinions. Now we have a few big players that can do this and more. Social media has turned into a war over who can blow the most filter bubbles, and with services like OpenID and "connect with facebook", everything has slowly become part of the same identity.

I'm hoping that a new platform will eventually come along to pry this apart, but it's going to take a completely different paradigm to cause it. Unless something like Google+ proves otherwise, websites like Facebook and Twitter et al have the potential to monopolize social networking.

<comment><USER34> I hope you don't mind a shameless plug, but I believe something like my startup might be this new platform of which you speak: <http://loggur.com>.

I'm not claiming that my startup in particular will be it, but something like it. Just saying this probably puts me in the category of "just another young whipper snapper who aspires to be the next Zuck"... but I have no desire to do anything like Facebook or Google or intentionally copy any particular model. I just want to do what works (well).

Loggur is clearly an infant at this point and I'm sure the initial impression given by its current presentation of the idea doesn't exactly scream "innovation" or "the next big thing"... but bear with me. I'm starting off relatively simple and will iterate as I get feedback (as is expected of any startup) but the general end result, as I envision it, will essentially be an extremely wide variety of user-editable tools specific to each user and/or community, from communication to productivity and automation - or both. I realize that the current presentation is pretty vague, but that will change after iteration and solid examples. The current descriptions are based on an alpha version which I put together earlier this year to prove the concept.

<comment><USER35> The concept of loggur seems interesting, but to be completely honest, I thought the "help us get featured on" written in small characters before the logos of TechCrunch, Mashable, etc. was deceiving in a really lame way.

<comment><USER34> I've seen other startups on HN do the same thing and received positive responses for doing so, which is why I did it. It seems to be a matter of perspective, I guess. As per your response, I'll make the "Help us get featured on" text larger. My intention isn't to be deceiving or lame. I just hope to someday be able to remove that text.

</comment></comment></comment></comment></comment><comment><USER36> this was quite insighful actually.

</comment><comment><USER37> daark. I get the uncertainty and fear of the 'seedy' nature of G+ and rise of the corporate platforms...but seems like more of us trying things out, learning, so we can maybe direct change/influence the evolution of the platforms....

</comment><comment><USER38> Someone call the UX police. Cannot read that. Looks like it got lost from 1995.

<comment><USER39> > Cannot read that

it's called 'text'. You've heard of 'words', yeah? Well text is just a collection of words - think of it like a photo album or playlist, but for words. We call them paragraphs.

The great thing about paragraphs is that you can group a whole bunch of words together to form more powerful concepts than the individual words themselves.

Paragraphs have a very simple UI - in fact you're using one right now!

</comment></comment><comment><USER40> Is the new web better at UX than this? That was painful to look at.

</comment><comment><USER41> And apparently the old web is filled with sarcasm and spite.</comment>


Sixth-Grade Developer Teaches Students How to Make Apps - <AUTHOR> http://www.good.is/post/this-sixth-grade-developer-is-teaching-students-how-to-make-apps/

<comment><USER2> This is really neat. It would be great to see things like this integrated into tools like codecademy so they could spread.

</comment><comment><USER3> Some kids become astronauts, should we start an aeronautics program in schools?

Lots of kids go into accounting, should we create an accounting program in schools?

Some kids go into engineering, should we create an engineering program at schools?

This kind of thinking is so dumb and short-sighted...

<comment><USER4> I'm not sure if you actually watched the video but it's clear that no "program" was created and that no education funds were supporting this young man. He used his own initiative to start a club at school and a single teacher sponsors the club. That's not a program. It's an opportunity for those interested in making apps to come together and share in the experience. Would aeronautics, accounting, or engineering clubs be beneficial to those interested in such subjects? Absolutely. There's nothing dumb or short-sighted in this young man's thinking. He thinks it's fun to share app dev with people who also think it's fun.

<comment><USER5> I think it's actually better that it isn't run by the school. Very few teachers would be cool enough to allow their kids to make fun or extremely random stuff (or if a curriculum was designed, it probably wouldn't involve celebrity-inspired Whack-A-Mole). Most programming curricula use contrived exercises and aren't nearly engaging enough for elementary school students. A student-led club on the other hand has the freedom to do anything the kids want.</comment></comment></comment>


Fix Radar or GTFO - <AUTHOR> http://www.marco.org/2012/05/08/fix-radar-or-gtfo

<comment><USER2> I once had an interesting experience when visiting Apple. I was telling a DTS engineer about a gnarly bug in the Cocoa text system I had found (certain text editing sequences would silently corrupt the undo stack; user might not notice until they accidentally did a select-all and delete, and then tried to undo to get their novel back).

I never got any feedback on this bug at all (just like always).

But, this Apple guy looked up the bug on their internal radar tool (a native Mac app, not some crappy web interface). There were screens full of discussion, with engineer's names I recognized, and the bug has been elevated to "Show-Stopper" status, which he told me meant the next release wouldn't ship without a fix.

What I took from this is that Apple's internal tools for bug triage, discussion, and prioritization are relatively sophisticated and heavily used, but they have nothing to do with the pathetic, rude, uninformative Radar interface that we peons who pay Apple for the privilege of developing for their platform get to see. It was kind of interesting to get a peek inside from their perspective.

Having said that, though, I almost never file Radar issues anymore, for exactly the same reason that I don't go to Apple's offices and clean their toilets for free.

<comment><USER3> I find the toilet analogy to be flawed. Sure you don't fix their toilets for free, but you would certainly let someone know if you used one of their facilities and found it to be clogged or otherwise malfunctioning.

As a someone who's filed a few Radar issues over the years, I understand that the lack of feedback is frustrating, but I find it absurd that the way to fix that is to withhold the bug reports that help improve the software we use and develop for daily.

<comment><USER2> Well no, to be honest, I certainly don't do that. If I am at say, Moscone Center or a Wal-mart or a low-rent casino, and a toilet is clogged with shit, I don't go wandering around to hunt down a maintenance man and report it to him. I just use another stall.

Now, if it was instead the toilet at a restaurant or other venue that I frequent, where I am welcomed and treated with respect, then of course I would alert the staff to their problem.

But a developer's relationship with Apple is much more the former than the latter. (I file really awesome bug reports for other software I use, like OmniGraffle or Arq.)

It's also important to note that I didn't _begin_ with this attitude; I _ended up with it_ after filing dozens of detailed Radar bugs over the years, and evaluating how shitty the response from Apple is.

As others have pointed out, if a developer spends 5+ hours isolating a crippling bug in your shit[1], and filing it with a repro case[2], and you don't even have the courtesy to let them follow changes to the bug when it's marked as a duplicate, then well... you're kind of a rude and arrogant asshole. So developers become less likely to keep performing this service for you... unless they _really_ _really_ _really_ want the bug fixed.

[1]<http://masonmark.com/the-xcode-fairy>

[2]<https://github.com/masonmark/XcodeCorruptOnOpenBugDemo>

</comment></comment></comment><comment><USER4> We (my company) have filed quite a few radar bug reports, including one quite serious flaw (account passwords being sent across a network in plaintext serious). We never heard a squeak back. We never know if they have, or will ever be fixed in a future release.

Some of these bugs affect our software critically, but we're completely in the dark about whether we should invest serious time and energy into providing our own workaround or leave it as it'll be fixed in the next Mountain Lion Preview.

This lack of communication is one of the worst things about being an Apple developer, and I fully support the community's efforts to try and persuade them to do better.

</comment><comment><USER5> I've filed many bugs with Apple over the years. There are two strategies which work:

1\. For security issues, use full disclosure. I received phone calls immediately when I included something like "disclosure in 30 days unless otherwise requested". Otherwise bugs were fixed in the next OS release a year later.

2\. Otherwise: our Apple rep (.edu) told us that bugs were prioritized based on how many Macs you couldn't buy until it was fixed. Later, this changed to how the bug was preventing you from deploying iPhones ("iPhone: it's like sudo for Apple") and I imagine this now includes iPads.

<comment><USER6> "Disclosure in 30 days unless otherwise requested".

I love this so much. "Unless otherwise requested". Perfect.

</comment></comment><comment><USER7> "Fix Radar or... Carry on making large sums of money regardless."

Developers aren't their primary concern. Look at Xcode for crying out loud (and wonder at its magical ever-crashing nature).

<comment><USER8> XCode has never crashed for me in 3+ years.

Your project is corrupt. You're doing something wrong. Look to a professional for assistance with your IDE.

<comment><USER9> You're not using Xcode. I mean Really Using Xcode. Like making a serious attempt at exercising its features. Hell, you really don't even have to do that. Create a project, edit some code, compile and run your app. That's usually fine. Now, try repeatedly, several times a minute for eight hours straight to use the debugger on your app (intentionally overrelease something or create some other reason for Xcode to launch lldb when your app crashes.)

Xcode will crash.

</comment></comment></comment><comment><USER10> This has been solved already: <http://openradar.appspot.com>

If you file a new bug with Apple, publish it here as well. No more black hole, you can see what others have already posted. You can even see what duplicates are about (if the original bug was also at open radar).

<comment><USER11> Interesting usage of the word "solved", there.

<comment><USER10> Yeah, well let's say "partially solved".

</comment></comment></comment><comment><USER12> Why would Apple want to "fix" Radar? It seems to meet _their_ requirements quite well:

\- Developers have a place that they can report things which is industry best practice

\- They don't need to put in as much money to staffing it

If it's a big enough issue then they'll hear about it through other channels.

(EDIT: formatting)

<comment><USER4> This is exactly why action on the part of developers is a good idea. Obviously Apple doesn't need to fix it, the current system is serving them well enough. Apple's target market are its users not its developers, and that's fine.

However, as a developer, I'm going to be trying my hardest to pressure Apple into making my life easier, and the more people doing the same the better. Just because they can get away with this sort of thing, and it makes logical sense for them to do so doesn't mean that's the way things have to stay. A better ecosystem for Apple developers is a better ecosystem for their end- users, down the line, anyway.

</comment></comment><comment><USER13> Did anyone else click on the link hoping for a nice juicy technical article about RADAR (<http://en.wikipedia.org/wiki/Radar>) and not some whining about a piece of software that would have been fixed by now if it was open source?

</comment><comment><USER14> I don't this is specifically an Apple issue either, I've filled bug reports on quite a few different projects (mostly open source) including at least one that's a full application framework and rarely do they ever move into 'confirmed' or 'accepted' status.

The entire reason of letting people add bugs is that they can be tracked, if the submitter can't track it then why would they want to add it? If you can't see a perceived benefit then you're going to lose interest in reporting the bugs which in the long term is bad for the overall package.

<comment><USER15> I believe that at a certain size of the project you will get more incoming bugs than you can handle. Doesn't matter if it's closed/open source, who the users are or anything else. It's just a matter of the number of users / size of QA.

Basically over some threshold you'll get conflicting behaviour expectations, duplicates formulated differently so they cannot be linked, QA finding more tiny issues in every release than bugfixes going in, etc. At least that's what I've seen so far from both open and closed projects.

(wxWidgets still takes the cake, asking me if the bug still exists after ~8 years since initial report)

<comment><USER14> True, it's definitely a case where eventually the number of bugs becomes incredibly difficult to manage but it's still essentially training people to not report bugs if they can't see even the smallest amount of traction on it.

</comment></comment></comment><comment><USER16> If you file a bug report on Radar, unless you know someone at Apple who you can give the Report ID to, it is unlikely to be dealt with quickly. Seems like they don't have a dedicated team overlooking it.

<comment><USER5> This is definitely false: they respond quickly with initial triage. The main problem is that you will subsequently almost never hear anything from them and if your issue was reported as a duplicate you'll need to manually poll them over email for the status.

</comment></comment><comment><USER17> There's already an effort to do this:

<http://fixradarorgtfo.com/>

500+ developers so far have submitted this to Apple.

<comment><USER18> If you didn't notice, this blog post is inspired by that site and links to it.

</comment></comment><comment><USER19> I'm not sure what the problem is. Apple has created a filter to bug reporting that they're clearly comfortable with.

<comment><USER18> The problem is that you can't get real tracking on your business critical bugs because Apple just marks them as duplicates. And once it's a duplicate, you can't see the status, so you never know if it's actually fixed. So why even bother reporting bugs?

Here are my stats from Radar:

4 Open - All over two years old.

7 Duplicate

1 Closed - The only one I got a response back on, and that Apple said was fixed.</comment></comment>


Zero to Profitable - LiberWriter Lessons Learned - <AUTHOR> http://journal.dedasys.com/2011/09/08/zero-to-profitable-liberwriter-lessons-learned <comment><USER2> Congratulations. I always love seeing folks go about doing something, particularly something which solves an actual problem for people.

There's always another thing to do, but I think you'll find that even in a non-technical niche you get non-trivial ROI out of grabbing one of the looks- a-wee-bit-more-professional $15 templates on e.g. ThemeForest or what have you. One of your core challenges at the beginning is convincing folks who _need_ to be published that you are trustworthy enough to give a credit card to even though you're on the big, scary Internet which is full of viruses and scam artists and other things preying on poor defenseless folks such as themselves. Design can help you do this.

<comment><AUTHOR> Yes, fixing up the front page some is certainly high on the list of things to do. I actually really liked the article about the HighriseHq.com restyling, but fear that a really fancy design like that is indeed a bit out of my reach, so maybe a theme like one of those is a better bet.

In terms of payments, one of the very convenient things about LiberWriter is that since people want to publish on Amazon, I use Amazon Payments without having to worry much about which system(s) to use.

They have to get that far to see that, though, and yeah, better design would help that. It's encouraging that it's making money even without that, though.

</comment></comment><comment><USER3> I've read your blog post with great interest before clicking through to your website. Let me tell you, after reading what you wrote, I expected pricing ranges starting from at least $200 (ok, that could be just me, but still - $50 is waaay to cheap). Your customers are people who spent weeks and probably months writing their Thing, and Kindle is probably the hottest publishing platform at the moment - and they are the people with serious problem of converting Word to Kindle. Us geeks, we often forget how it feels not to know what we know, how it feels not to be a geek. In my line of business, I deal with many non-technical people, and they are scared and intimidated by all this technology and software.

What I'm trying to say: What's a $100, $200 one time fee compared to the possibility of making a writer's dream true? It's possible you're leaving serious money on the table and methinks you can get very, very - rich in the Kindle business (I surely hope you do, because I think you provide a very valuable service).

What if you tried experimenting with pricing?

<comment><AUTHOR> Prices definitely need to go up. I've done some research and have some ideas, so I'll be implementing that shortly, with a discount for current customers as a way of saying thanks for signing up.

There are some upper bounds to the price, because most self-published authors are not 'rolling in it' either, and at a certain point they'll just give up and do it themselves.

</comment></comment><comment><USER4> > without easy access to venture capital and the huge talent pool that area > has, should consider, rather than trying to copy what makes Silicon Valley > work like it does.

This is spot on advice. In Canada, it's a big deal when companies get $25K investments from an angel or a special program.

I still remember a pamphlet from Startup Weekend in which a local fund in Toronto had pictures of startup founders smiling behind oversized checks for $10K-20K.

The disadvantage over the Valley is huge if you try to play the same game.

For example, starting Twitter in Canada is an exercise in futility. You simply don't have the external funds to let it grow.

It's far better to be the 37signals of Canada, and grow the business through paying customers. This way you can grow organically and sustainably and perhaps even get noticed by VCs at some point.

</comment><comment><USER5> Hello David, congratulations! What a fantastic service you have. I can wait to start writing my book to use it :)

I do have one suggestion (I'm pulling this one out of my a... and you could easily check the validity by looking at the analytics):

If you make your logo smaller, you could bring the call to action (the view plans... button) above the fold (at least at 1280x800 which is pretty standard on mac laptops), giving it an immediate exposure.

If your analytics tell you that an important percentage of your users are in this screen resolution or near, it might be a very easy way to increase your conversions.

Not only that is incredibly easy to measure it :) (Google WebOptimizer, <http://www.optimizely.com>, <http://visualwebsiteoptimizer.com/> Owner is very active on HN)

If you ever decide to try it out, share the conversion results?

Would love to see if it helped :)

</comment><comment><USER6> Congrats with your project David! I see a lot of potential in that market as it is possible that traditional publishers will eventually fade away in the "kindle era". Have fun with your business!

</comment><comment><USER7> Congratulations! Always liked the idea (huge potential and other related services could be launched) and i was waiting for a post like this :)

</comment><comment><USER8> Congratulations.

Do you mind sharing some numbers or maybe explain what you mean by profitable (ramen? nice-living? about-to-hire?)

<comment><AUTHOR> On good days it's close to what consulting pays over here, so somewhere between ramen and decent living, with a trend upwards. It's not 'get rich' stuff, but for me this was one of the critical points of Rob's book - if you make something that's hugely profitable, expect lots of others to jump in too. If you do a niche well, perhaps it's easier to set things up and keep going.

<comment><USER9> _if you make something that's hugely profitable, expect lots of others to jump in too._

Yes, I know the feeling ;)</comment></comment></comment>


Researchers still don't know why this Atari 2600 game works - <AUTHOR> https://www.techspot.com/news/85622-nobody-sure-what-makes-atari-2600-game-entombed.html <comment><USER2> This is a regurgitation of the BBC's original:

[https://www.bbc.com/future/article/20190919-the-maze- puzzle-...](https://www.bbc.com/future/article/20190919-the-maze-puzzle- hidden-within-an-early-video-game)

</comment><comment><USER3> TIL there are Atari 2600 game researchers.</comment>


Parsing and formatting date/time in Go - <AUTHOR> http://pauladamsmith.com/blog/2011/05/go_time.html <comment><USER2> So they appear to be aiming for consecutive numbers:

      Mon Jan 2 15:04:05 MST 2006  (MST is GMT-0700)

      Month: 1
      Day: 2
      Hour: 3 (15 being 3pm, or 03 for 12-hour clock)
      Minute: 4
      Second: 5
      Year: 6 (2006)
      GMT offset: 7 (well, -7)

But this is confusing for anyone outside the US, because the month is 1 and the day is 2. I would probably need to dig out the docs to figure out:

      01/02 03:04:05PM '06 -0700

because of the ambiguous 01/02.

Also having the year consecutively after the time is a little weird.

Seems like big-to-small ISO times (year, month, day, hour, minute, second) might have been a better choice. They're logical and unambiguous, irrespective of locale. And the clear consecutive order helps with memorability. e.g. in consecutive-number order:

      2001-02-03 16:05:06 GMT-07:00

<comment><USER3> Totally agreed, I like the idea but the numbering scheme really leaves me scratching my head.

Going big to small would be way nicer, especially if that was the standard representation as then you'd get lexical ordering for free within time zones.

I can't imagine these guys made that decision lightly, they are too smart for that, there must be some other background to it.

</comment></comment><comment><USER4> I've never come across this way of laying out the date:

        "01/02 03:04:05PM '06 -0700"

What about correlating the mnemonic digits to period sizes:

        "06/05 03:02:01PM '07 -0400"

(with timezone offset coming between hours and days)

This would correspond to iso:

        "2007-06-05T03:02:01.0"

<comment><USER5> I agree, numbering it in order of period sizes would be easier than remembering the arrangement of the canonical form, especially for international users.

(Also, it would be "2007-06-05T15:02:01.0")

</comment></comment><comment><USER6> I find that I need to lookup the special values when writing Go time format strings. In this regard, Go time formatting is no better than strftime.

The win comes from reading format strings. I find that it's obvious what the format is supposed to do with out looking at the doc.

</comment><comment><USER7> it is simpler to remeber that those formatting characters.

Let's not forget: go has a very simple way to implement your way of doing things from any pkg, struct. just implement a func (p *SomeNewCoolTimeDate) Format( layout String) as you see fit.</comment>


Ask HN: Job Advice/Suggestions - <AUTHOR>

Unfortunately it appears that I have outgrown the company I currently work for. They are wanting to focus mainly on simple, static, 'marketing' websites whereas I want to focus on more sophisticated and large scale projects. I have been hesitant to move away because the company has treated me well over the last 2 years, but it's become clear that I am earning less than I should, I no longer enjoy the work and there's no real upward path (very small company).
I have been looking for opportunities for a while but I haven't found any that match my skills. I'm by no stretch of the imagination a 'junior developer' but I don't have the experience with deploying/maintaining large applications that would get me entrance to the 'senior developer' positions.
Has anyone else found themselves in this position? How did you approach the problem?
FYI: My web-development experience 4(ish) years, general programming experience 8+ years. <comment><USER2> Have you just been looking passively, or have companies told you that you're unqualified for postings? I went through a similar situation at work, and decided to interview for a few positions. The "senior" position listings were definitely willing to speak with me, interview me, most of the time. A few said they wanted somebody with the experience, but by and large, they were willing to talk.

The great companies, i.e. the ones you seem to want to work for, will actually appreciate this attitude. Desire for challenge is probably one of the more significant factors startups look for in early stages -- they want you to overextend yourself and learn from it. So it can be a plus, as long as you frame your responses properly (not, "I'm a hobbyist looking to get a little better," but, "I'm a professional who wants to become a guru."

And lots of times the folks writing the job descriptions don't know the programming industry -- they just write what got them their last hire in that position.

I think you should pick out a few jobs that seem ideal to you, and try to interview for them. You'll learn a lot about yourself in the process.

As for me, I stuck in my current job, because I found that it was easier to speak with my supervisor about finding different work areas to keep me challenged, as opposed to changing jobs. That's always another option you should look at as well.

<comment><AUTHOR> I've been just looking passively. There are a couple of issues that I have to overcome. One is that my resume _really_ doesn't reflect my experience or knowledge. I tend to do a lot of side-projects, many of which may never end up being viable products, but ones that I gain a lot of great experience from. The problem is that in many cases I know I can do the job, but I can't back that up with material proof (except by maybe interviewing with someone that can quiz me on the technical issues).

I totally get where you're coming from about shooting for the interview. I think that's a very good point.

As for moving around within my current company: unfortunately that is not really an options. The company I work for is _very_ small (6 people) and to change the type of work I aim for the whole company would basically have to shift it's focus...

Insightful though! Thank-you!</comment></comment>


Ask HN: Planning for living in SV/SF - <AUTHOR> Does anyone know of blogs or guides (or is willing to share personal experience) about what living in SV/SF is like in terms of expenses for a new software engineer at one of the larger tech companies?<p>Assuming I land a job like that, I'm really concerned that I won't be able to live here in the long term. It seems like the cost of living is so high that no one can really afford anything, so I'm hoping to understand if there's a path to a sustainable lifestyle. <comment><USER2> I've been living in SV on and off for the better part of my 20s now. I make much less then most software people but have managed to make it by financially out here.

My best advice would to be open of the idea of not living alone (at least while you first come out here). Find like minded roomates in a house in and pay 600-900 bucks for a room.

I barely make 60k a year and am doing it just fine I just don't get to have the same perks as othera.

</comment><comment><USER2> Establish yourself in the industry and save your money. Then you can take your talents else where and live in a location with a normal housing market and habe nice things.</comment>


Ask HN: Is the 'new' page the best way to pick news? - <AUTHOR>

I feel that new submissions have a highly randomized chance of getting picked up by upvotes due to the nature of the new page.
There are already a lot of submissions, and depending on the rate of submissions at the time you submit, and the number of eyeballs on the new page, it is a matter of chance that a good submission catches any interest.
I would rather prefer that the effect of luck is reduced and good submissions always get picked up. For example, new submissions could be organized in a different way for people to upvote. E.g. I should be able to have a day's worth of time window to check new submissions and upvote them, and search for keywords in submissions. Any comments? <comment><USER2> I tend to stick with the "new" page, yes. I prefer stability, and I know that when I return to that page I'll immediately see what is different (i.e. what's at the top). Then again, I probably check the site more often than most people.

I imagine the "crowd-sourced" front page is the most useful to people who won't be taking the time to click a lot of "More" links and just want to read a few interesting things.

Another reason I check "new" is because I occasionally flag things, and it's unlikely that posts requiring a flag are going to appear anywhere else.

</comment><comment> saiko-chriskun I also read hacker news off the 'new' page. I find many interesting links that don't make it to the front page, and I don't find it very difficult to keep up with, but again I 'spose that depends on how often you're willing to keep up with it :P.

Plus someone has to give those initial upvotes :P

</comment><comment><USER3> I think the whole idea of an aggregator is that some users will prefer the new submissions and some will prefer the aggregated results. Neither is best but the "new" section is required for the model.</comment>


9cc: A Small C Compiler - <AUTHOR> https://github.com/rui314/9cc <comment><USER3> Regarding your Makefile; you should still pass CFLAGS through to the compiler when linking, not only LDFLAGS. Suppose CFLAGS contains -m32 (supported by an x86-64-targetted GCC to do 32 bit). You compile the .o files with that, but then link without it, which fails trying to make a 64 bit executable out of 32 bit .o's. Some crazy distros pass a --sysroot in CFLAGS; if you don't have that, your build finds the wrong library and header files.

Even when linking, don't call "cc", but "$(CC)". You're relying on the implicit rule to compile your .c to .o which will use $(CC). $(CC) could be some ARM cross-compiler supplied by a distro. When you link using "cc", you end up using the build-machine's native compiler.

Write the build system like this is an awesome program that major distros will be eager to pick up, and make it easy for the package maintainer. :)

Speaking of CFLAGS, only set that conditionally; don't clobber it:

      CFLAGS ?= -O2   # Only if CFLAGS is not specified externally, use this default

for things that your program needs in order to build right, put that in other variables of your own:

      DIALECT_CFLAGS := -std=c11

      CFLAGS += $(DIALECT_CFLAGS)  # integrate external CFLAGS with our own.

Same deal with LDFLAGS. Both CFLAGS and LDFLAGS can include important things that cause a bad build if you mess with them.

<comment><USER4> Where would one go to find more of this conventional Makefile wisdom? I've had so many issues trying to use make the "right" way (flexible, clean, terse, etc.).

I feel like one of the best ways to acquire this wisdom is to post a project with lots of mistakes and let people tear it apart.

<comment><USER5> [https://nostarch.com/gnumake](https://nostarch.com/gnumake)

<comment><USER6> That is not, contrary to what the name might imply, the official GNU Make manual. That one can be read here, for free: [https://www.gnu.org/software/make/manual/](https://www.gnu.org/software/make/manual/)

<comment><USER5> I don't take the name as implying that.

Anyway, it is excellent and has some good advice and tips.

Unlike the official manual which is more a reference.

</comment></comment></comment></comment></comment><comment><USER7> [https://github.com/rui314/9cc/blob/882e4b2dd8/main.c#L7](https://github.com/rui314/9cc/blob/882e4b2dd8/main.c#L7)

        int main(int argc, char **argv) {
          ...

          Vector *tokens = tokenize(path, true);
          Program *prog = parse(tokens);
          sema(prog);
          gen_ir(prog);

          if (dump_ir1)
            dump_ir(prog->funcs);

          optimize(prog);
          liveness(prog);
          alloc_regs(prog);

          if (dump_ir2)
            dump_ir(prog->funcs);

          gen_x86(prog);
          return 0;
        }

This is wonderful.

<comment><USER8> And also wonderfully devoid of error-handling, too. It's the most common way for beautiful-looking C code to look beautiful.

<comment><USER9> A compiler is in the happy position where there is little point in continuing to run after encountering an error, so it can bail right out with exit(2) after reporting the error to the user. This means that the contract on parse(), for example, can be that if it returns, it has succeeded.

<comment><USER10> Except of course LLVM has proven the value in not assuming this pattern & building your compiler as a library of which the executable entrypoint is but one frontend.

<comment><USER11> Exceptions are the exit() of libraries. Or if you're using plain C, setjmp/longjmp might be a good idea, depending on what you're doing.

</comment></comment></comment></comment></comment><comment><USER3> Small nitpick. Functions in C that take no arguments are written name(void){...} not name(){...}. This latter form is an old-style definition which doesn't introduce a prototype into the scope.

For functions that have prototypes, it is okay, but when they do not, you're losing type checking (yes, even on the number of arguments).

The following program compiles with no diagnostics for me with -W -Wall -ansi -pedantic, with GCC 7.3 on Ubuntu 18:

      int func()
      {
        return 0;
      }

      int main()
      {
        func(3);
        return 0;
      }

-std=c11 (as you're using) makes no difference.

The same is not true of C++: func() in C++ is a prototype definition. C++ supports (void) for compatibility with C, but even in nonsensical contexts: class::class(void);

<comment><USER12> Quote from 18.104.22.168.14 of the C++11 spec ([http://www.open- std.org/jtc1/sc22/wg14/www/docs/n1548.pdf](http://www.open- std.org/jtc1/sc22/wg14/www/docs/n1548.pdf)):

> An identifier list declares only the identifiers of the parameters of the > function. An empty list in a function declarator that is part of a > definition of that function specifies that the function has no parameters. > The empty list in a function declarator that is not part of a definition of > that function specifies that no information about the number or types of the > parameters is supplied.

So, my interpretation is that the following two function _definitions_ define the same function of the exact same type

      void func() {}
      void func(void) {}

although the following two function _declarations_ declare two functions of different types

      void func();
      void func(void);

<comment><USER3> That is of course the C11 (draft) spec, not C++.

Interesting find there. The wording is also in the C99 draft; it is not new.

It is in fact saying that the empty list in a definition is a special case and does declare that the function takes no parameters. To "specify" here can be understood to mean as inserting information about type into the declaration scope; that which a declaration does.

So that's a bit of a bug in GCC there; it should be treating this the same as (void) and therefore diagnosing that way. If not by default, then at least when -pedantic is applied. But nope:

       $ gcc -Wall -W -std=c11 -pedantic proto.c
       $

<comment><USER13> My understanding is that, unless you have a function prototype, you will lose type info about the parameters:

"The empty list in a function declarator that is not part of a definition of that function specifies that no information about the number or types of the parameters is supplied."

i.e. the most important is the end of that sentence, so GCC behavior should be right.

<comment><USER3> Note the: _" that is not part of a definition"_.

This is about declarations only.

</comment></comment></comment></comment></comment><comment><USER14> I'm rewriting 9cc with Rust from first commit. [https://github.com/utam0k/r9cc](https://github.com/utam0k/r9cc)

</comment><comment><USER15> Good to see more C/subset-C compilers being written. Besides the immense pedagogical value, they are also useful for preventing the "trusting trust" attack: [https://dwheeler.com/trusting-trust/](https://dwheeler.com/trusting- trust/)

I will also make a suggestion to use precedence climbing instead of plain recursive descent for the parser; it makes the parser even simpler and table- driven, which is important with a language like C that has many precedence levels.

<comment><USER16> Interesting, do you have any useful links related to this concept?

<comment><USER15> Here is the discussion of the original Trusting Trust attack: [https://news.ycombinator.com/item?id=13569275](https://news.ycombinator.com/item?id=13569275)

<comment><USER16> Thanks I was referring to precedence climbing parser part of GP reply.

<comment><USER17> [https://eli.thegreenplace.net/2012/08/02/parsing- expressions...](https://eli.thegreenplace.net/2012/08/02/parsing-expressions- by-precedence-climbing)

Precedence climbing is also (intimately) related to Pratt parsing, and there's a useful series of articles about the two here: [https://www.oilshell.org/blog/2017/03/31.html](https://www.oilshell.org/blog/2017/03/31.html)

</comment></comment></comment></comment></comment><comment><USER18> It lists a goal as "compiling real-world programs such as the linux kernel"

The last time I investigated the linux kernel had so many gcc-isms that it was probably true that if you could compile the linux kernel, you could probably compile any program targeted to gcc.

<comment><USER19> Other "alternative" compilers like tcc have pulled it off, supposedly without patching the kernel, so it is doable.

<comment><USER20> Does tcc compile a vanilla kernel? I know tccboot added some minor patches:

[https://bellard.org/tcc/tccboot_readme.html](https://bellard.org/tcc/tccboot_readme.html)

</comment></comment></comment><comment><USER21> Interesting to mention: the author of this compiler, Rui Ueyama, is also a developer at the LLVM project. He's one of the most active developers of LLD, LLVM's linker.

</comment><comment><USER22> How does this compare to Nils Holm's subc compiler that has somewhat similar goals? There is a book describing the compiler as well (though the current version of the compiler supports a larger subset of the C language).

[https://www.t3x.org/subc/index.html](https://www.t3x.org/subc/index.html)

</comment><comment><USER23> I really wish people would choose better names, we just had an hyphen and it becomes a C dialect from the early 80's.

[https://en.wikipedia.org/wiki/Small-C](https://en.wikipedia.org/wiki/Small-C)

<comment><USER24> "a small c compiler" is just the description, "9cc" is the name itself, so there's not much similarity there...

</comment></comment><comment><USER25> I wonder if this is a reference to the band 10cc - [https://en.wikipedia.org/wiki/10cc](https://en.wikipedia.org/wiki/10cc)

<comment><USER26> G is the 7th letter of the alphabet

<comment><USER25> It took me a distressingly long time to figure out what you meant by this.

</comment></comment></comment><comment><USER27> How does this compare with tcc?

</comment><comment><USER26> kparc.com/b

</comment><comment><USER28> >no memory management is the memory management policy in 9cc. We allocate memory using malloc() but never call free().

>I know that people find the policy odd, but this is actually a reasonable design choice for short-lived programs such as compilers.

I'm strongly disagree at this point. Memory management is important even for short-lived programs. It would bring burden to the OS if you invoke this kind of "short-lived, memory-management-free" programs multiple times.

>This policy greatly simplifies code and also eliminates use-after-free bugs entirely

Not facing it is definitely not a good way to solve a problem. It's a bad attitude as a programmer be honestly.

<comment><USER29> > Memory management is important even for short-lived programs. It would bring > burden to the OS if you invoke this kind of "short-lived, memory-management- > free" programs multiple times.

All the memory is freed when the process exits. Why does it matter if you run the program multiple times?

<comment><USER30> It will put more pressure on the allocator when running, doing that a lot will likely have some kind of cumulative consequence down the line. I know from experience [0] that even reusing allocated memory rather than bouncing it back to malloc can have dramatic effects.

[0] [https://gitlab.com/sifoo/snigl/blob/master/src/snigl/pool.h](https://gitlab.com/sifoo/snigl/blob/master/src/snigl/pool.h)

<comment><USER19> Malloc doesn't interact with the kernel at all. The kernel sees pages, not the data structures that malloc manages. The kernel doesn't even know whether you free()'d the memory by the time the process exits.

There is exactly zero difference from the operating system's perspective between freeing and not freeing the memory before program termination (except that one might have a higher peak memory usage).

The classic implementations of several standard Unix utilities deliberately never deallocated memory for performance reasons. If there was a problem with this practice, I would expect Bell Labs--of all places--to know not to do it.

<comment><USER31> > _There is exactly zero difference from the operating system 's perspective > (...)_

Close, but not quite: in case of larger allocations, malloc() tends to use mmap( , , , | MAP_ANON) rather than brk() to request memory from the OS. For example, the glibc's malloc() uses mmap() when requested size exceeds MMAP_THRESHOLD, which is 128kB by default.

The mmap() approach gives large, continuous memory blocks that can also be easily free()'d via munmap() with little to no bookkeeping needed[1] - <USER2> being subject to the same fragmentation woes as memory allocated via brk() - as long as your address space is significantly larger than allocated memory.

That aside, I fully agree with the author of 9cc.

[1] in fact a simplistic libc memory allocator could directly wrap malloc() around mmap(), free() around munmap() and realloc() around mrealloc(), leveraging the in-kernel allocator at the cost of one syscall with at least two context switches at each call - i.e., _slowww_

<comment><USER19> An implementation certainly _could_ return memory to the OS on calls to free(), but to my knowledge none of the widely used implementations do so. (I would be interested to learn of counterexamples!)

<comment><USER29> jemalloc can use madvise(MADV_FREE) to return pages to the OS.</comment></comment></comment></comment></comment></comment></comment>


Show HN: My Cool CV - <AUTHOR> http://mycoolcv.com/

<comment><USER2> With complete respect and admiration for your efforts, I don't feel like signing up because it looks atrocious. I know the project may be low budget, but even if it's free, you still need to sell it to your target market.

</comment><comment><AUTHOR> A friend just launched their Cool CV service. Please let us know your thoughts, ideas, or questions.

</comment><comment><USER3> This page doesn't look good enough to convince me, that you can create beautiful cv.</comment>


Uniregistry New GTLDs Prices Increasing 3,000% - <AUTHOR> http://domainincite.com/21603-schilling-big-price-increases-needed-to-keep-new-gtlds-alive <comment><USER2> So, just as we expected, new TLDs are just a cash cow for registrars.

And something for the rest of us to immediately add to spam filters.

Great. Just great.</comment>


Bike lock developed that makes thieves immediately vomit - <AUTHOR> https://www.theguardian.com/lifeandstyle/2016/oct/21/bike-lock-developed-that-makes-thieves-immediately-vomit <comment><USER2> So the protection mechanism can be defeated by a gas mask.

<comment><USER3> You'd still probably have to throw away your clothes aftwards.

<comment><USER2> So $2 worth if op shop clothes for a new bike...</comment></comment></comment>


Customers You Do Not Want - <AUTHOR> http://insight.kellogg.northwestern.edu/article/the_customers_you_do_not_want/ <comment><USER2> This was not what I expected. I thought it would be about toxic customers. It's actually about a set of very good customers who happen to like products that are doomed to failure. The idea is that some people have a distinct out of the mainstream taste. Kind of like when I tell my daughter I like her outfit so of course she won't wear it again.

<comment><USER3> It's really about a basic misunderstandingof statistics.

Some people prefer to buy novel products. Most novel products fail to get popular. Therefore, there is a correlation. There was no finding that such customer prefer _unpopular_ new products over _popular_ ones.

<comment><USER4> I interpret the article as a finding that there exists some "bland/mainstream vs novel/unique" scale that actually is objective - i.e., corresponds to measurable and consistent preferences for groups of customers.

There actually _was_ a finding that the analyzed customers historically preferred novel-flavor products over mainstream ones. This means, that if those customers really like your product, then that's some evidence that it may fall into the same group as the other niche products

</comment></comment></comment><comment><USER5> Two things strike me.

1\. Are these people just general 'early adopters'? Anyone who's willing to try new stuff is going to use products that ultimately fail in the marketplace. This is the whole 'Crossing the Chasm' story.

2\. Are these people merely flitting from product to product? In other words, they drink the new Cola A now but will immediately switch to even newer Cola B tomorrow. Thus, they're not really reliable long-term customers. The article gives the impression that this is not case but it's not that clear to me.

In any case, this comes down to a question of market size. If that niche is big enough, there may still be a profitable business in it. For example, how many people do you think need a service that makes Bingo Cards?

<comment><USER6> From the article: "The worst of the harbingers? Repeat customers, those with a tendency to purchase a product like Diet Crystal Pepsi not just once, but over and over again. These customers really, really like the products that end up failing. Harbingers with a history of making four or more repeat purchases of a failed product are nearly twice as likely as other customers to buy another product that fails."

So no, it doesn't seem like it's as simple as early adopters or novelty- seekers.

<comment><USER7> The stats (as they are quoted here) are just exactly what you would expect to see if you looked at early adopters.

New products typically fail. If you are a consistent early adopter, you will buy a lot more failures than someone who sticks to tried-and-tested products.

If anything, "twice as many" is lower than I would have thought. In my opinion, this suggests that early adopters are rare - that there isn't a novelty-seeker type of person who goes around trying new products for the sake of it.

What they should be measuring is slightly different than this. If these people buy a new product, does that make the product more likely to fail than it would otherwise? (Given that the product is likely to fail anyway)

As I've understood, this stricter statistic is not seen in the article. Even if we could identify people like that, I would put those people into the category of "temporarily unlucky early adopters" and would not expect them to have predictive power.

With that in mind, the conclusion of the article seems nonsensical.

<comment><USER4> The conclusion is that if you make a new product, you should ignore data from "typical early adopters" but look at "boring people with strong habits".

If people who ordinarily don't try new stuff are buying your product, then it will be a mainstream success.

If they don't, then noone cares if the consistent early adopters think that your product is great.

</comment></comment></comment></comment><comment><USER8> This is pretty interesting but may not be so relevant in the context of digital products or doing a startup. Yes, we want our products to be mass market from day 1 but if your low-capital 2-person company can get traction in a 1% niche market then you'll have money to focus, retarget, and grow to 2%, 4%, 8%. Pepsi, on the other hand, needs to pay for inventory, shelf space, marketing, and distribution so their profit margins probably depend on mass market adoption. They're also in a position where it's more profitable for them to just axe less popular products and try again rather than steal shelf- space and mindshare from their big sellers.

<comment><USER9> Yes, I had a similar issue with this article; sometimes, appealing to a niche market IS a path to success. There are countless successful business that cater to smaller market segments.

<comment><USER10> The article is about product development in retail. If you're not planning on selling your product via a major retailer then this article doesn't apply to you.

</comment></comment></comment><comment><USER11> I wonder if this works for TV shows.

I know plenty of people who like all/most of Firefly, The Sarah Connor Chronicles, Dollhouse, Defying Gravity, Almost Human, etc.

All shows that got cancelled after a season or two because they failed to attract a wide enough audience.

<comment><USER12> SciFi is niche to begin with. I can think of _very_ few SciFi shows that ever achieved mainstream appeal (call it 3+ seasons).

Of course, when you think about it, what's the percentage of normal shows that actually get 3+ seasons?

The difference may not be the percentage but the rabidity of the fanbase.

</comment></comment><comment><USER13> "Harbinger of failure" seems to be a misnomer, given that the article does show any way to pragmatically identify these users - the only way seems to be with the benefit of hindsight. A 'harbinger' requires predictive value, not post-mortem value.

Edit: To be a bit clearer, they do mention a sort of weeding out of users, but this requires deciding beforehand what 'mainstream' is and then (effectively) looking for confirmation bias.

<comment><USER14> This seems, at least, to be aimed primarily at market research professionals at the sort of level who would be able to access things like loyalty program data and so forth to provide an initial pool for focus groups, etc. The advice is predictive in the sense that it says "eliminate people whose purchase patterns have consistently exhibited product loyalty to failed products in the past from the pool", and that the people who insisted that "butterscotch sardine supreme" would be a _killer_ flavour for potato chips in your last market test, losing you millions (since your hundred positive testers were the _entire_ market for the flavour), probably shouldn't be part of your next market test.

Product tests are a lot like private software betas - people who actively participate and provide more than the minimum feedback tend to be called on again and again. The advice here is to stop calling on people who tell you to do stupid things.

<comment><USER13> Your explanation makes _far_ more sense than the article: when you're looking at your pool of informants, weed out the ones with a track recording of previously liking failed products. Basically you're selecting for selective fitness. The article doesn't put this very clearly at all.

<comment><USER15> I felt the same way. I basically got that point from the article, but there's a lot of verbiage to weed through. Could have been much more concise and direct.

</comment></comment></comment></comment><comment><USER16> It's worth skimming the (still incomplete) paper rather than just reading the article. The article misses a key point made in the paper: repeat purchases by 'harbingers' was found to be an informative feature, in predicting whether or not a new product would succeed.

[http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2420600](http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2420600)

<comment><USER17> tl;dr but did they actually show that the 'harbingers' were predictive or were the 'harbingers' just correlated with failure? It is really easy to find correlation when you start trawling through a large dataset but which all dissipate to nothing once you start using the correlations to make predictions.

<comment><USER16> Predictive, not just correlated.

</comment></comment></comment><comment><USER18> A grain of salt: these insights don't strike me as relevant if your market is over-saturated (i.e. end-user mobile apps, web frameworks, etc).

Appealing to a niche is -- as far as I understood it -- a good way to stand out in a "me too" marketplace.

Assuming the niche is large enough and isn't already satisfied by your competition, the real challenge is retaining those niche customers.

</comment><comment><USER19> These are the customers that you do not want for a product with fixed costs (like Pepsi).

For an web-based product, the customer you do not want is the free user who uses up huge amounts of tech support time.

</comment><comment> at-fates-hands It seems to me yes they are niche customers, but also having ever changing tastes in things. Not like early adopters, but will buy a unique product for short time until they find the next unique product they like or get bored and move on.

More like short attention spans more than anything. I mean, how long can someone who's never had diet crystal Pepsi drink until they get bored with it? Or until their friends stop asking them what it is their drinking and hop on the next "cool" product coming to town.

</comment><comment><USER20> Sounds to me like they just analyzed a bunch of data and found that there were some people, in that historical data set, who consistently bought products that fail.

For this to be science, instead of just finding random correlations, they'd have to take those people and see if they _continue_ to buy products that fail.

Otherwise, sure, I have no doubt in any big enough data set, there will be some people that happen to have done whatever you want to find. Doesn't mean there's any predictive power in it.

</comment><comment><USER21> I suppose the basic thesis is: given support by a potential prospect for a new product, check what other products they have lent support to. If those products are still around, great. If not, you might have a problem. Or more succinctly: "You don't want people that buy failed products to buy your product--and if they want to, you should change your product"?

I suppose I could believe this. But there's probably a lot of ways to interpret that data. And it seems to be about CPGs (not that that makes it worth more or less, just that CPGs have different dynamics than a lot of other industries).

Parallels to software industry: fickle users that don't want to give you negative feedback for fear of discouraging you (when in reality, they may be saving you from blowing your life savings on an ill fated concept)? Be careful with interpreting the results of customer development (or the CPG parallel-- focus groups) Certain types of early adopters should be avoided (how does this square with Crossing the Chasm concepts?)

Maybe similar to how some people find themselves consistently in bad relationships, some people find themselves buying products that are doomed to fail time and time again? Perhaps they wonder why they can't just find a good product that's willing to stick around for awhile...

</comment><comment><USER22> The general idea is reasonable ("in product study, make sure your sample is representative") but the recommendations are problematic.

Obviously if you just put a product in a store for a certain period of time, only pay attention to the sales numbers, and then try to make claims about the number of potential buyers in a larger population, you're going to have a bad time. (hello selection bias)

But watching out specifically for people with niche preferences in some area is not at all the answer. Barring some very strong data showing otherwise, there's absolutely no reason to suppose that a person with niche movie tastes also has unorthodox tastes in dish cleaning liquids. Now, of course, if you're about to market a Swiffer-lookalike product, whether a certain study participant likes Swiffer is an interesting variable to record. But then, you probably don't need that study all that much in the first place compared to someone who's about to bring to market a bold new product.

And of course this is just basic statistics -- do a good job randomizing your sample, and pick sample size that's large enough for your desired confidence interval.

<comment><USER22> Oh ok, there's a linked research paper and it's more nuanced. It might actually have some data to support their claim that if a buyer has kinky tastes in toothbrushes, it also spreads to toilet paper.

</comment></comment><comment><USER23> I think there's a lesson here that might be applicable to, say, JavaScript frameworks, devops tools, or maybe even programming languages. If you're building a new JavaScript library, and you're getting lots of positive feedback from people who have tried everything except jQuery, you're probably not creating something with mass appeal...

</comment><comment><USER24> My guess is that the "harbingers of failure" are just anti-popular-item folk. They like an item because other people (read: the huge market a company actually wants) don't like it, or because it's "different." Not because it has actual inherent new value, or actually tastes good. Perfect setup for failure -- tons of people dislike your product, and the only ones who like it are the ones who like it because others don't. Cases in point my guess are Crystal Pepsi (as the article uses), another is Zima[1], a third is Orbitz[2].

[1] [http://en.wikipedia.org/wiki/Zima](http://en.wikipedia.org/wiki/Zima)

[2] [http://en.wikipedia.org/wiki/Orbitz_(soft_drink)](http://en.wikipedia.org/wiki/Orbitz_\(soft_drink\))

<comment><USER25> I hate that they and you use Pepsi Crystal as an example. I loved it!!!

</comment></comment><comment><USER26> _" These customers do not seem to be shopping at odd hours, and they are not any more likely to pay full price for the products, both of which might indicate that they are less alert or savvy than other customers."_

Did anyone else read that as "too drunk or stoned to know the difference"?

</comment><comment><USER27> Fairly trivial article which fails to state its primary assumption: it is talking about mass-market FMCG (fast moving consumer goods) which want immediate success. This is why we have tens of varieties of instant coffee but no 'cold concentrate' type liquid coffees.

Claiming that niche consumers are the kiss of death is obviously news to many makers of luxury goods (and companies like Apple who do not cultivate mass markets but end up creating them because the niche users ended up being right).

</comment><comment><USER28> On the other hand such products could sustain a lifestyle business with a sort of 1000 True Fans model.

Obviously for a mega corp stocking shelves at a B&M store such niches are not going to be viable, but for e-tailer that should be less of an obstacle.

</comment><comment><USER29> Let's be clear: this is about bringing mass-market products to market, not niche products like most people on HN are building. This article considers a niche product to be a failure.

</comment><comment><USER30> If this is true, seems like a good idea to go through everyone that backed my Indiegogo and check on the status of the other projects they funded...

</comment><comment><USER31> Hmm where is the data behind this?

<comment><USER32> The original research paper is linked at the bottom:

[http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2420600](http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2420600)

</comment></comment><comment><USER33> This explains why many products I love go away. Dammit.

</comment><comment><USER34> I was promised a long tail.

<comment><USER35> Here: [http://www.curiositiesbydickens.com/wp- content/uploads/cat-w...](http://www.curiositiesbydickens.com/wp- content/uploads/cat-with-long-tail-feathers1.jpg)

The idea that the Internet will bring the long tail of products and services is bullshit and shows scant recognition of how economics works.

If anything, the Internet will serve to cut our existing tail shorter.

</comment></comment><comment><USER35> > Just as positive feedback from lead users signals that a new product will > likely succeed, positive feedback from harbingers signals that a new product > is likely to fail.

Straight from the "creepy similarities" department:

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

Vocal geek minority supporting your product for righteous reasons means your product will fail.

</comment><comment><USER36> Nice post!</comment>