New errors in IPCC climate change report - Telegraph - <AUTHOR> http://www.telegraph.co.uk/earth/environment/climatechange/7177230/New-errors-in-IPCC-climate-change-report.html <comment><USER2> The whole area of Scientific Publishing is in need of a major shift by disrupting current practices - and I am hoping when it does is a YC start-up.

While studying for my PhD, a pattern arose - any papers written before 1975 provided adequate details to reproduce results down to code or references to Technical Reports that provided this information.

What I would like to see.

(01) Any research that is publicly funded to make all publications, data and code freely available. (Not behind paywalls)

(02) All papers to have more than one version, version 2 being a good explanation of what the research is all about, results etc - without the jargon, in order for readers to better understand the subject and delve further into it, should they wish.

(03) A comments section

It is as if suddenly Scientists are afraid of standing up and support their theses. A more open policy on publishing - in detail - on the web can help them do so, they can crowd-source opinions and suggestions - really I don't see a downside to this.

Out of curiosity I spent over a week to find out the roots of experiments that determine the effect of CO2 on temperature, if the models took account of diffusion, which layer of the atmosphere is affected the greatest etc... So far I have not been very successful.

<comment><USER3> The criticisms in this article have little to do with peer review. In fact, the whole _problem_ is that the IPCC panels appear to have incorporated non- peer-reviewed papers in a few locations in the reports about impacts and mitigation. Peer review is not falling apart, despite breathless claims to the contrary.

<comment><USER4> " _In fact, the whole problem is that the IPCC panels appear to have incorporated non-peer-reviewed papers in a few locations in the reports about impacts and mitigation._ "

There's no "appear" about it, they've been forced to admit it.

Saying they used garbage "in a few locations" severely understates the damage, e.g. they shouted from the rooftops that the Himalayan glaciers would disappear by 2035 (which turned out to be a terrible mistake for them, since India had no choice but to take a rigorous look at their claims ... which the Indian head of the IPCC then claimed was "voodoo science", something he later had to apologize for).

Peer review "is not falling apart", but it's taken a severe body blow. No longer will anyone be taken seriously who stakes a claim on the basis that it was peer reviewed.

<comment><USER3> _"Peer review "is not falling apart", but it's taken a severe body blow. No longer will anyone be taken seriously who stakes a claim on the basis that it was peer reviewed."_

No, you're exaggerating.

There's a difference between peer-reviewed scientific publication, and what the IPCC does, which is to aggregate and summarize the findings of peer- reviewed scientific publications. And though the panels assembling the IPCC report let through some questionable material, these errors of inclusion neither invalidate the hundreds of other lines of evidence in the reports, nor do they invalidate the system of peer review.

(Also, not incidentally: claiming that the glaciers are melting more _slowly_ than argued in the IPCC report doesn't mean that they're not melting.)

<comment><USER4> What I'm referring to when I say "stakes a claim" is a) the sort of thing the IPCC does, science _policy_ , and b) the documented abuse of the peer-review system by ClimateGate conspirators.

And that's quite bad, since the point of a fair amount of science is to have real effects on the world at large; both these abuses is going to make that much harder. They could also have bad effects on science funding ... why should people trust such a system?

Potentially worse is that this general group of people has been crying wolf since the '60s (no later than the publication of _Silent Spring_ in 1962). One day we might truly face an existential threat and our ability to deal with it will almost certainly be crippled since we've been hearing a "we're all going to die!!!" message for half a century, and we're still here and seem to be doing quite well (e.g. life expectancy is going up).

</comment></comment></comment></comment></comment><comment><USER5> It is curious that for a community which theoretically worships peer review that increased scrutiny into their methods starts to come up with all sorts of low-hanging fruit like this.

I kind of feel sorry for them: humans make mistakes, and retrospective digging into any human endeavor is going to uncover them. That wouldn't be a problem if their marketing hadn't been "This is the infallible Voice of Science: the only people capable of understanding it all have already signed off on it. Implement our recommendations or be cast into a fiery pit." Mr. Wizard always looks less impressive from behind the curtain.

I have half a mind to take a week or two this summer, grab one of the old papers in the field and the associated data sets, and just try to reproduce the math. The reason I have only half a mind is that I know I'm likely to discover that the process is not covered in sufficient detail publicly to reproduce it.

<comment><USER6> It's difficult to know what to make of this. There seems to also be such a massive disconnect between other media voices over what the impact of revelations like this are to the overall global warming / climate change thesis.

There has been a stunning lack of intellectual curiosity/skepticism by journalists on the issue and if anything, much of the media seems outright hostile to the possibility that the overriding thesis could possibly be wrong.

This wouldn't be such a big issue if it weren't for the policy recommendations that would have us greatly change our way of life by people who by and large are insulated from proving their work has intrinsic value/subject to markets/or even the costs if they're wrong. It is to the Telegraph's credit that they've stayed on this story but I'm not sure if I'm more surprised or worried that these revelations have not caused a greater level of introspection or reached a wider mainstream audience.

That said, it would seem at least the news is trickling out: <http://news.bbc.co.uk/2/hi/science/nature/8500443.stm>. It does make me wonder even more about the news industry before internet use became pervasive.

<comment><USER7> "his wouldn't be such a big issue if it weren't for the policy recommendations that would have us greatly change our way of life"

The whole point of implementing cap-and-trade is so that we don't have to significantly change our way of life:

[http://correspondents.theatlantic.com/conor_clarke/2009/06/d...](http://correspondents.theatlantic.com/conor_clarke/2009/06/daily_chart_what_waxman- markey_will_do_to_the_economy.php)

<comment><USER6> The Obama administration internally believes that cap and trade will cost the average family $1761 USD/year: [http://www.cbsnews.com/blogs/2009/09/15/taking_liberties/ent...](http://www.cbsnews.com/blogs/2009/09/15/taking_liberties/entry5314040.shtml) \- and that's their estimate that's almost certain to be light ignoring the impact on industry itself.

Now what happens in actual implementation? Read [http://www.aolnews.com/world/article/europes-cap-and- trade-m...](http://www.aolnews.com/world/article/europes-cap-and-trade-model- loses-billions-to-fraud/19274092) and [http://www.theaustralian.com.au/news/health-science/csiro- bi...](http://www.theaustralian.com.au/news/health-science/csiro-bid-to-gag- emissions-trading-scheme-policy-attack/story-e6frg8gf-1225793355139)

<comment><USER8> Well, cap-and-trade will be partly offset by peak oil causing less of a shock.

<comment><USER4> Which assumes that, this time, the Peak Oil crowd is right.

I see no reason to give them any more credence than the last N times they've claimed this (my personal knowledge goes back only to the"Limits to Growth" '70s, but you can go back many more decades).

</comment></comment></comment></comment></comment></comment><comment><USER9> The minute I saw people calling those who dispute the accuracy of findings, "Climate Change Deniers" I realised that this was less about science and more about politics.

The science should stand up on it's own two feet, it shouldn't need 'consensus' from closed groups. Release the data and the methods and we'll find out what's really happening by putting the hypothesis under scrutiny.

<comment><USER10> On the one hand, it isn't right for anyone who questions the science (which is, after all, the _point_ of science) to get stuck with a highly pejorative label.

On the other hand, what else do you call those who are so convinced of a One World Government conspiracy that they refuse to accept the very notion that humanity can cause long-term damage to the ecosystem? They're out there, I've met quite a few.

<comment><USER11> One can reject AGW and accept that humanity is causing long term damage to the ecosystem. Your comment reads like a noble lie,

"well maybe the science is a little shaky, but we need to implement these policies {driving less, energy reduction, limits on emissions, etc} so let's just get on with it"

<comment><USER10> I do think _some_ "green" policies (alternative fuel sources, such as solar and nuclear) make a lot of sense whether or not AGW is true, and in those instances we should act before the science is in. But I didn't mean to imply such an either/or, "you're with us or you're against us" position.

My point is that such extremes of position _do_ exist, and that there are people who genuinely believe that since our habitat has been (mostly) ideal for thousands of years, that it will continue to be so forever, and that it is impossible for humanity to alter that, despite centuries of heavy industry. And those folks have their head in the sand w/r/t science and reality, every bit as much as those for whom AGW is unquestionable dogma.</comment></comment></comment></comment>


Tetuan Valley Startup School Spring 2010 Graduation video - <AUTHOR> http://blog.tetuanvalley.com/2010/05/tetuan-valley-startup-school-spring.html

<comment><USER2> My midichlorians multiplied after watching this video! :)

Participating in TetuanValley was great fun, I highly recommend it to any entrepreneur in the Madrid area.

</comment><comment><AUTHOR> Congrats to all surviving teams!

</comment><comment><USER3> Great video! Great experience!

</comment><comment><USER4> Amazing video! haha so funny!

</comment><comment><USER5> Awesome resume video!!! ;)

</comment><comment><USER6> This video rocks!

</comment><comment><USER7> Nice video</comment>


Ask HN: Hypothetical acqui-hire scenario - <AUTHOR>

So let's take this scenario.
Currently employed making $150k as an engineer at a well known tech company, but you're not in love with your position and want to move in a new direction.
You have developed some type of mobile technology in your spare time that demos super well, but is hard to productize/scale. Now your goal is to leverage that technology into getting a new leadership position at a different company and getting 1 million dollars in your pocket in the process possibly through an acqui-hire.
There are three potential companies
Company A) Small private company that has similar mobile technology 50 employees, $30m venture funding
Company B) Large public tech company (Yahoo/Google/Microsoft)
Company C) Established private tech company (Uber/Spotify/Etsy)
What would you do and why? <comment><USER2> Depends on your appetite for risk.

B will likely pay you in stock and/or stock options of which some portion will immediately vest and be sellable (albeit with substantial taxation). But at least it will be liquid.

A and C will both likely pay you in stock options or units. But since the companies are not public, you won't realize this wealth until a liquidity event (like an IPO or a buyout). That maybe years away, and a lot can happen between now and then.

All three options can be made less risky if they offer cash, but of the three, A and B are likely to offer more cash.

Career wise, it's going to be very dependent on who the acquirer is and has less to do with the stage they are in and more to do with their culture around acquisitions. They might want your technology or they might want you, but it's very rare that they'll want both.

<comment><USER3> Very rare?

If they want your technology, it's probably cutting edge and sophisticated. Which means they need someone to help bring it on board, and support it for awhile. If they didn't want you along, that'd be very very dumb.

</comment></comment><comment><USER4> Talk to all three. Pitch your idea, then play hard to get.

Tell them, 'As you can see I'm super busy and choosy who I who work with. Now I'd like to hear from you guys, how this technology might integrate into your platform, and what it might look like if we partnered on building something together'. The winner will become obvious.

Hat-tip to Oren Klaff > [http://www.goodreads.com/book/show/10321016-pitch- anything](http://www.goodreads.com/book/show/10321016-pitch-anything)

<comment><AUTHOR> Awesome.

Do you approach them, as customers, partners or acquirers?

<comment><USER4> This is develops into a discovery conversation. You may be open to a variety of scenarios.

</comment></comment></comment><comment><USER5> All of the above. IMHO fostering an atmosphere of competitive bidding can help light a fire under otherwise slow-moving suitors.

Also, taking every meeting gets you well-practiced and minimizes the risk of any particular acquirer dropping out.

I would add that option D is letting your current employer get in on the action. They'll likely not have it in their budget, but giving them the opportunity to acquire your app might be good politics in the end.</comment>


Bilinguals experience time differently from monolinguals - <AUTHOR> https://cordis.europa.eu/news/rcn/128246_en.html <comment><USER2> Being a trilingual (funny enough that two of the three are Swedish and English) this is a little bit of a stretch in terms of the title. I would not say experience, and instead maybe (according to the article) say measure time in different forms. Short vs. Small; a minute is a minute.</comment>


Marissa Mayer Pledges to Take Yahoo Back to Its Roots - <AUTHOR> http://mashable.com/2012/10/22/marissa-mayer-yahoos-future/ <comment><USER2> > Flickr for Android

What? Since when has this existed? Lovely to learn of this the day after my 2-year Flickr Pro account expired.

Seems like it's been out for over a year. And I never found it before I gave up looking. Too little, too late, I guess. For Mayer's era's sake, I hope that's not the rest of Yahoo's fate.

<comment><USER3> Over a year ago?

<http://mashable.com/2011/09/28/flickr-android-app/>

<comment><USER4> I don't understand your question . . . that blog post is a year and just short of a month old.

</comment></comment></comment><comment><USER5> No offense to her but does Mayer really know Yahoo's roots?

<comment><USER6> Yahoo's roots are... a tardily updated directory of neat things on the web.

It had a certain amount of charm, but I don't miss it, particularly. Although they did have a great MUD index.

<comment><USER7> IIRC (it's been a while), Yahoo's roots are the librarian approach to the problem of organizing the world's information: classification, taxonomy, Dewey-Decimal, directories and subdirectories, whatever.

I prefer Google's approach to the problem (massive silicon replacing wetware). But, being much lazier than the average slacker, I could be wrong.</comment></comment></comment>


Super-capacitor Wires, for use in electric cars - <AUTHOR> https://drive.google.com/file/d/0B8_BGWWMS8QhakJyZGRJSkROSzQ/view?usp=sharing

<comment><AUTHOR> A more detailed paper can be found at [https://drive.google.com/file/d/0B8_BGWWMS8QhaUtOeXJGVU9vVmM...](https://drive.google.com/file/d/0B8_BGWWMS8QhaUtOeXJGVU9vVmM/view?usp=sharing)

The research team that wrote these papers is working on bringing the wires to the commercial market through electric cars and other devices.</comment>


Ask YC: Founders, at what point do you incorporate / form an LLC? - <AUTHOR>

My guess is that most web-based entrepreneurs start off just by putting their site online and seeing what interest there is. That is, any income from the site just goes directly to the founder.<p>At what point do you take the next step and form a real business entity like an LLC or corp? <comment><USER2> Most common events that trigger incorporation: 1\. if you are taking outside investment 2\. if you and your cofounders need more than each other's spoken agreement regarding % ownership and vesting schedule 4\. Offering service/product for which you might want a limitation of liability 3\. need to take advantage of deductions for business expenses to offset any other income you may have coming in (thought you could do this through DBA filing as well)

<comment><USER3> spoke to a "in the know" silicon valley lawyer about this a few days ago. two of the three triggers he mentioned are similar to the one posted by tandaraho: 1) when you need to limit exposure to liabilities (e.g., from customers/clients/users); 2) when you've developed intellectual property that needs to be assigned to an entity; 3) when your business partner(s) need firm clarity on where everyone stand.</comment></comment>


Millennials Are Worse Off on Average Than the Generation Before Them - <AUTHOR> https://www.bloomberg.com/news/videos/2018-06-01/millennials-are-worse-off-on-average-than-the-generation-before-them-video <comment><USER2> Who would have thought. It's only going to get worse.</comment>


Apple Releases iOS 4.3 Beta - <AUTHOR> http://www.macstories.net/news/breaking-apple-releases-ios-4-3-beta/ <comment><USER2> Wheee! Third-party apps can now play video to Airplay devices! (off by default, which sucks and means updates will be needed to enable it).

Other than that - some minor iAd functionality, access to some additional metadata for media files, and playback stats for videos (frames dropped, bytes sent) and that's about it. At least on the API side.</comment>


FFaaSS – Free Function as a Service Stack (The Free Stack) - <AUTHOR> https://www.linkedin.com/pulse/free-function-service-stackffaass-stack-ramon-lima/ <comment><USER2> I think this idea is brilliant! A list of free web services and resources such that someone could cobble their own dynamic website or web service for free...

What might even be more interesting is if someone actually used this stack to create something profitable... That would be a newsworthy article, wouldn't it?</comment>


An alternative introduction to Rust - <AUTHOR> http://words.steveklabnik.com/a-new-introduction-to-rust <comment><USER2> I'm a Python user, and always dipping my toes in other tech, working through books on Go, wrote some Node servers and so forth. I rarely find something that has enough advantages to warrant augmenting or replace Python or bring it into 'my stack'. The time involved to really master these things isn't worth it, in my opinion.

Something with no GC for hard real-time systems would fit the bill, also something that I could write performance-critical libraries with a C ABI like Rust to call from Python. I've had my eye on Rust and of course C(++), but mostly waiting for Rust to stabilize before diving in.

Guides like this are going to mean a lot in the coming months for people like me who are Rust-curious but don't have a systems programming background.

I'm not so much looking for yet-another-scripting language or GC'd language but a systems language that perfectly augments my Python/SQL knowledge.

Thanks for doing this, Steve.

<comment><USER3> You should consider the Nim language. It "feels" like Python but has seemless integration with C, and native performance like C.

[http://nim-lang.org](http://nim-lang.org)

<comment><USER2> I did at one time. I've been keeping my eye on Nim (though a far less watchful one than on Rust) to see if the standard library works one day without using the GC.

</comment></comment></comment><comment><USER4> In what sense this introduction is alternative? It's just like every other intro that explains basic and easily understood things about the borrow checker, but doesn't go into details on how you actually live and work with the damned thing. The second thing you do after learning basics is trying to implement some simple data structures, like lists, or even (horror!) double- linked lists. In Rust this is the moment where you start hitting roadblocks, and then you read somewhere that implementing "basic" data structures in Rust isn't a basic exercise at all, and that is kind of discouraging.

<comment><USER5> This seems like an unfortunate pathological case caused by the abstraction level Rust sits at. The kinds of tree- and graph-like data structures that garbage collected languages can represent in safe code (at the cost of performance) don't work as well in Rust; you can still implement them with various mechanisms (std::swap is very important for trees; Rc and Weak; replacing pointers with indices into a global Vec; etc.), but due to a desire to get optimal low-level performance, core data structures often end up using unsafe blocks in their implementations. The thing is, though, implementing data structures is something of a worst case: in most other code you can _use_ the data structures to provide the pointer relationships you need, but when implementing them you have to do that yourself. Most other code is more naturally amenable to working with the borrow checker - which is not to say it's not difficult.

<comment><USER6> This isn't unique to Rust, in fact, as modern C++ presents the same dilemma. Here [1] is a Stack Overflow question where someone asks how to make a doubly- linked list out of smart pointers, and all the answers either involve shared_ptr or C pointers. Same pedagogical issue: you want to deemphasize the less-safe pointers (in Rust, the ones behind an "unsafe" gate; in C++, the raw C pointers) in favor of the safer abstractions, but you hit a wall when it comes to doubly-linked lists.

C++ has it easier in practical terms, I guess—few projects _actually_ use smart pointers as pervasively as modern C++ guidelines stipulate (and they're hard-wired into the language in a couple places like operator new and this), so C pointers usually have to be taught pretty early anyway. In Rust, by contrast, unsafe pointers are considered evil things you touch only when you know you have to. But the problem is still there: it feels like something that comes with the territory of manual memory management in general.

[1]: [http://stackoverflow.com/questions/15384443/doubly-linked- li...](http://stackoverflow.com/questions/15384443/doubly-linked-list-using- stdunique-ptr)

<comment><USER7> I don't get why they just don't suggest using weak_ptr<>() for the backwards reference.

<comment><USER8> You need to use weak pointers for backpointers in Rust, because there's no GC. If you create a cycle with reference counted objects, objects are never released and the program will leak memory.

<comment><USER7> Of course, but my question was _why it wasn 't explained_, I know very well the reason why weak pointers are required.

</comment></comment></comment></comment></comment></comment><comment><USER9> I suggest you go with prose that clearer over prose that is more stylistic. For example:

 _Line six has a closing curly brace, and so main, and thus, our program, is over._

Could be rewritten as:

 _Line six has a closing curly brace, and so main is over. By extension, our program is over as well._

Maybe even with a quick reinforcing of the (hopefully earlier explained) concept that main is the main program block.

It's a fine line to walk, making the text interesting while also making it _very_ clear, but I think there's something to be said for making the English easy to parse, since the people going through the tutorial will have enough on their hands dealing with the code examples.

<comment><USER10> I agree. Dedicated tutorial authors of languages with advanced concepts such as Rust, Haskell, etc. really need to take a course or have a quick overview of technical writing. Steve does a pretty good job with Rust, I think. I wish Haskell had good tutorial authors like Steve. Haskell really needs better tutorial authors.

Are CS majors typically required to take a technical writing class like other engineering disciplines?

<comment><USER11> I had to take one. All I remember from it is making posters and graphs. We didn't actually learn BETTER WRITING in it, but how to write RFCs.

</comment></comment></comment><comment><USER12> > Rust's variable bindings are immutable by default, but can become mutable, > allowing them to be re-bound to something else

From someone reading about these details for the first time:

Calling them _variable_ bindings confuses the matter. You say, just moments earlier, that _variables are called by that name because they can change over time, they're mutable_. But this _variable_ is immutable? But only sometimes? !

I know you mean that the mutability varies and that it makes sense in the context of the jargon of functional languages, but that's something that will make sense to language developers who have worked on Rust for years and maybe to the HN crowd, and not to new coders trying to grasp difficult, novel (to them) concepts.

How about "multimode bindings" or "multiphase bindings" (as in liquid/solid phase transitions) or dual-mode or something more entertaining like "double- agent bindings". Is it too late to change?

Maybe I'm missing something, but I suspect years from now people will be saying, 'so _variable_ bindings are not always variable? huh?'

<comment><USER13> 'Variable' is a jargon-y term in mathematics/programming in general, it doesn't literally mean "this thing can vary in the run of this program", e.g. even Haskell calls its name bindings "variables", and it is focused on immutability much more than Rust (I suppose this is the functional programming aspect you were mentioning).

One way to view it is that the bindings don't have a value that is fixed at compile time: they vary between runs.

In any case, I'm not sure what you mean by "mutability varies".

</comment></comment><comment><USER14> It definitely feels a little long winded for a person with some background already in systems langauages like C. Do you plan a TLDR for systems language people?

<comment><AUTHOR> A Redditor put it best:

        > My only concern is that lot of the motivating of the ownership
        > system seems to be directed at C/C++ programmers, but at the same
        > time you're explaining pointers and memory management as almost new concepts.

I think this is a weakenss of this draft, yeah. I want to make it accessible to non-systems people, but also okay for systems people. In the current, actual intro, I treat everything at a high level, looking downard occasionally. This version is more about starting down and looking up, but it might be not enough detail for the non-systems crowd (there's still tons of implicit knowledge here, even though I tried to spell it out) and a bit tedious for the systems crowd (who have intenrnalized much of this already.)

Writing is hard.

<comment><USER15> What about two intros? One for the low levelers, one for the high levelers? It's extra work, but it allows to treat more appropriately what each side needs to learn.

As [1] says: "Rust for C programmers != Rust for functional programmers."

[1] [http://science.raphael.poss.name/rust-for-functional- program...](http://science.raphael.poss.name/rust-for-functional- programmers.html)

<comment><AUTHOR> Also very possible. It's something I've been considering for a long time.

</comment></comment></comment></comment><comment><USER16> I really like your writing style - it's a little verbose in places. The paragraphs detailing what each line number does would be easier just as pictures / diagrams with arrows to the source code sections. Likewise quite a lot of this could be made mode succinct, which would aid readability.

Along with that, it's really hard for me to get used to right-hand line numbers. Shoving them along the left hand side like most editors would be much much much easier to read for me, at least.

That said, I do enjoy your writing and find it quite readable.

<comment><AUTHOR> Thanks! It is a bit verbose, that's what I was going with with this version. You have to explore the extremes before finding a comfortable medium, you know?

I do agree better diagrams would help, for sure. And yeah, the right hand numbers were kind of a compromise: they kept the exercises compileable without needing to mess with markup stuff, which is just a weakness of markdown :/

<comment><USER17> What confused me was that the piece just seemed to stop, without a proper ending. It told me that "Rust stops you doing X", but not "And here's how to do it correctly in Rust."

</comment></comment></comment><comment><USER18> Steve, really great work, I've appreciated all your efforts as I've played around with Rust as it approaches 1.0. I think this kind of really deep treatment of an important topic belongs _somewhere_ in the introductory docs. I especially like that you give concrete examples of the problems that Rust's concept of ownership solves. The memory diagrams are actually quite helpful (IMHO) regardless of the "direction". Keep up the great work!

<comment><AUTHOR> Thank you!

</comment></comment><comment><USER19> I wonder, for people coming from non-systems programming languages (e.g. Python), whether it would help to visualize what is actually happening under the hood in a scripting language and comparing that to Rust. As others have noted, this guide is written as if to C/C++ programmers, while the intention (I had thought) was to also target scripting language folks?

My experience, having started in C++, then gone to scripting languages, then come back again, is that it can be quite helpful to consider what actually happens under the hood in a scripting language. Because Python's references are more limited, you would never exhibit the same bug that you illustrated in C++, but there are still issues around e.g. aliasing which tend to trip up inexperienced Python programmers, and where you could illustrate interesting things about Rust's ownership model. And boxed/unboxed data types plus reference counting (in Python) would give you an excuse to talk about RAII. So I think that you could do this in a way that would actually speak to savvy scripting programmers, while still being definitively systemsy.

Just a thought.

</comment><comment><USER20> Hm, I too got the sense that it's not clear what the "prerequisites" are for reading the article. Parts of it were really straightforward to me "oh, I know roughly what a stack and the heap are" to confusing "wow, I don't know anything about C++". I think a few distinct guides targeting different sorts of programmers might be the answer here.

But I do like the idea of focusing on ownership and lifetimes more front and center, since that's rust's raison d'etre.

Can you get a hold of Niko's slides from the NYC meetup this week at Bloomberg? I was there, and his overview of ownership and borrowing, using the examples of a book, were actually really helpful for me. For whatever reason, his approach really resonated with me.

</comment><comment><USER8> It's still too confusing. Try drawing actual pictures to illustrate the scope/lifetime issues. Talking about addresses on the stack is an implementation detail.

Things to cover:

Basic lifetime concepts in Rust:

       1.  Scopes are nested.
       2.  Variable lifetimes are tied to scopes.
       3.  Unlike other languages, variables can be created
           tied to a scope outer to the one where they are
           created. The user can control this by indicating
           that the lifetime of a variable is the same as that
           of some variable from an outer scope. This is Rust's
           big innovation.
       4.  A function can create a new object and return it by
           reference if the function explicitly says that the
           new object has the same lifetime as some parameter.

Basic ownership concepts in Rust:

       1.  There are three kinds of ownership - single ownership,
           reference count multiple ownership, and thread-safe reference
           count ownership.
       2.  The reference count ones work like you'd expect.
       3.  Single ownership interacts with the lifetime system in
           to make it possible to create data structures such as
           trees, with all components single ownership and having the
           same lifetime.
       4.  The "=" operator usually means "move", and when it does,
           the right hand side of the "=" becomes inaccessable.
           (This is type-dependent; some types copy when "=" is used.)
           This preserves single ownership.

Basic data structure concepts in Rust:

       1.  Rust has enums, which, unlike enums in other languages, can
           have data objects associated with them. They're really variant
           records.
       2.  You can declare an enum with a data object as a field in a
           structure. This creates a structure that contains (really links
           to) another data object.
       3.  This can be done recursively, so you can create trees of
           structures.
       4.  You can't violate the rules of single-ownership.  Trees are OK;
           directed acyclic graphs or backpointers are not allowed using
           single ownership.
       5.  There's no "Null". Instead you create enums which have one value
           with an associated data item and one without.
       6.  Everything has to be initialized to a valid value for its type.

Basic borrowing concepts in Rust:

       1.  You can create temporary references to something with an equal
           or longer lifetime, because the temporary "borrowed" reference
           cannot outlive the thing it is referencing. That's safe.
       2.  You can have one writer (a mutable reference) or N readers
           (immutable references) at a time.

Basic type concepts in Rust:

       1.  It's complicated.
       2.  There's automatic type inference.  Not just for "let", either.
       3.  Function parameters have to be declared, not inferred,
           except for the special syntax for closures that lets you write
           concise lambda expressions.  This limits how hard the
           type inference system has to work.
       4.  I don't fully understand Rust's type system yet.

Basic safety concepts in Rust:

       1.  All of the above is enforced at compile time.
       2.  The result is memory safety.

Misc. notes:

      - Lifetimes are novel, but not that complex.
      - The type system really is complex.
      - There are generics and you'll need them more often than in C++.
      - The compiler first checks syntax, then types, then borrowing. It does not report
      borrow errors until everything else is correct.
      - There are no exceptions, and proper error handling requires rather verbose code.
      - Have a plan for your variable lifetimes before you start coding, or you end up
      fighting with the borrow checker and losing.
      - If you think you need "unsafe" in pure Rust code, you're doing it wrong.

<comment><USER13>
       3.  Unlike other languages, variables can be created
           tied to a scope outer to the one where they are
           created. The user can control this by indicating
           that the lifetime of a variable is the same as that
           of some variable from an outer scope. This is Rust's
           big innovation.

This isn't quite right (or I'm not understanding what you're trying to say).

Given

       let x = 1;
       {
           let y = 1;
       }

there's no way you can make `y` itself live as long as `x`.

       4.  The "=" operator usually means "move", and when it does,
           the right hand side of the "=" becomes inaccessable.
           (This is type-dependent; some types copy when "=" is used.)
           This preserves single ownership.

I think this is "complicating" how =/moves work: it's really binding things by-value that are moves, the = operator isn't special. E.g. `foo(x)` will move `x` into the `foo` call, despite there being no `=` at all.

       2.  You can declare an enum with a data object as a field in a
           structure. This creates a structure that contains (really links
           to) another data object.

I don't understand this, could you clarify?

      - The type system really is complex.

I don't think this is very true, what complexity do you see?

<comment><USER11> I think traits are really confusing (dispatch by input AND output type), there's also trait inheritance, trait bounds, casting things to traits; add type inference to that, lifetime parameters and generics. You get things like

        struct Foo<'a, P>
            where P: std::ops::Neg + 'a,
               <P as std::ops::Neg>::Output: 'a {
            foo: &'a Bar<P>,
        }

after further research this makes sense, of course, but looks like non-sense to anyone just trying to learn the language

<comment><USER13> Hm, maybe I just "know too much", but it seems to me that most of the parts of the type system are relatively independent: there's not too many weird interactions between the various parts, and many systems are complex because of the surprising interactions.

In any case, half the "complexity" in the example you give is the noise of using the fully-qualified std::ops::Neg path in the bounds, rather than importing it and just writing `Neg`. :)

<comment><USER21> TBH whenever I see type names being added to each other, my brain kind of shuts down the relevant lobes. Granted, I'm barely initiated to Rust, but... it just looks confusing. (It doesn't help that it's not actually type names, but a type name and a lifetime...)

</comment></comment></comment></comment></comment><comment><USER5> I agree with some of the caveats listed by other people here (in general, that this guide seems wishy-washy about what type of programmer it's catering to), but I like the memory layout tables. While I don't remember much about how I thought at the time I might have benefited from such a tutorial myself, when these days I mess around with exploits and the like which do weird things to memory, it often feels surprisingly grounding and illuminating to open up a debugger and start printing the contents of memory, even if on a theoretical basis I already know what it's supposed to look like.

But please make it clear that the tables don't accurately describe the real layout of memory in a compiled Rust program. Heap mappings and thread stacks are typically at random (thanks to ASLR) addresses, rather than the start and end of memory, and the locations of specific heap allocations are usually based on complicated rules depending on the size class of the allocation (differently sized objects never get allocated together in most allocators), thread caches, ordering of buckets within a page, etc. (Some architectures also grow the stack the other way.)

<comment><AUTHOR> Yes, it's always about the right level of abstraction. Making it clear that it's not _actually_ 0x00 would be good, but then you can get into discussions about virtual memory, and all that other stuff that you're talking about, which just muddies the point of the example. It's a fine line.

</comment></comment><comment><USER22> I like the new structure much better!

Now, I'm in no way a writer. English isn't even my main language.. So take this next point accordingly:

Unfortunately, I get an even more condescending vibe from this draft than I got from the book. Not as in "I'm an expert and you're treating me like a newbie," but as if I was a kid instead of an aspiring Rust programmer (beginner or otherwise). I wish I could point out -exactly why- I get this feeling, but I'd be lying.

I do think I'm starting to see a pattern, though, that perhaps contribute to this gut reaction. The pace between concept introductions is odd, somewhat erratic. At times, in one line you're talking to a complete novice programmer, and the very next you assume they know other languages and general concepts [1]. Other times, you take some basic knowledge for granted and explains it right after [2]. I know it must be very hard to find the right balance for your target audience, but I found these jumps very jarring. For what it's worth, once you get past the introductions you pick up a more to-the-point- explanations rhythm and that reaction goes away.

[1]: For example, after several paragraphs and two code snippets to introduce the concept of 'variable bindings' in a novice-friendly way, even going as far as (somewhat) explaining what system and functional languages are, the text suddenly assumes I know about program execution and what a control flow structure is?

> As you know, a computer program is executed line by line. At least, until > you hit a control flow structure, anyway.

This line was specially off-putting. After all that explanation, the assumption I'd know this made me feel like a kid. But I can only imagine how inaproppriate I'd feel if I didn't know. Given the novice level of the text up to then, the 'as you know' sounds very out of place.

[2]: The very next paragraph, we go over a program with one variable binding line by line. And then, it's assumed I know about scopes. But after that they are explained anyway. I realize this is a way to go over every concept, even if one already knows them, but it feels odd! Both beginner and experts would understand a plain explanation. But this back-and-forth about how to present concepts doesn't work -- for me. It'd make more sense to read straight-forward explanations of what I already know than these "as a programmer, you know that x," mixed with even simpler concepts being introduced as new.

This sounds harsher than I planned -- I'm no writer afterall! But, really, despite these gut reactions, the Rust book is turning into one of my favorites. Thank you for all your work!

<comment><AUTHOR> > I wish I could point out -exactly why- I get this feeling, but I'd be lying.

It's hard, for sure. There are certain sentence structures that strike certain people this way, and my style sometimes triggers them. For example, "basically" has no negative connotation for me, but really gets some people going, so I've been eliminating it wherever possible. I wonder which aspect does it for you... thanks for the brain dump, this is helpful.

</comment></comment><comment><USER23> I liked the structure of the guide. However pairing the memory tables while mentally executing the code line-by-line got confusing for me. (Especially because the code was offscreen because the tables take up vertical space)

I'd love to see this kind of explanation done in a non-text medium. For example, a slideshow or interactive webpage (ex: [http://www.redblobgames.com/pathfinding/a-star/introduction....](http://www.redblobgames.com/pathfinding/a-star/introduction.html))

<comment><AUTHOR> I really wish I was better with front-end tech, creating those kinds of things would be awesome, but above my skill level, unfortunately :/

</comment></comment><comment><USER24> I was actually reading the rust lang book for the first time yesterday, specifically the intro to lifetimes that this post is a revision of.

I'm not sure jumping so much into what's going on in the C++ side is a great idea. The section as it stands now covers the important points (with out lifetimes invalidating pointers is easy) without getting too lost. However, I'm already pretty familiar with C++, so the more brief explanation may not be enough for everyone.

</comment><comment><USER25> I like it, but I would make two suggestions

1) There are many memory schemas for the push_back example, maybe you want to organize them side-by-side with an arrow between them showing which statement caused the change. Saving some vertical space may do some good.

2) I'm not a fan of the sentence structure in many places. Needs more pith. Perhaps apply some Strunk & White and some K&R.

</comment><comment><USER26> That was great, I was completely unfamiliar with Rust's borrowing system and now I think I understand it!

<comment><AUTHOR> Thanks!

</comment></comment><comment><USER27> Steve, great work! I know how hard it is to write so clearly.

The only quibble is that I'd make the middle slog a little bit shorter, maybe laying out the vectors horizontally instead of vertically, so people wouldn't forget what the text was about by the time they get to the end of the diagram.

<comment><AUTHOR> Thanks!

Yeah, the layout could be much better, and it'd be neat if I could use real diagrams with arrows as the pointers, maybe.

<comment><USER28> I thought this intro started really clearly, but I did get bogged down a bit matching up the pointers as numbers. So yeah, I think diagrams with arrows would be a lot easier to follow. I remember seeing a talk from Niko with animated box/arrow diagrams that changed as a piece of code executed (alongside a code snippet with the relevant code highlighted). That was super slick, and I thought it really helped make things clear.

Also, is it standard to talk about memory growing "down" as the memory locations numerically increase? That's the opposite of my impulse (I would have said that 0xff is the top of memory, and 0xfe is "down" from there) but TBH it's been a while since I took the relevant CS class.

</comment></comment></comment><comment><USER29> So basically, anyone who doesn't already really appreciate Rust must not know what a stack is, what a pointer is, or what immutability is?

I'm sorry, but this implication enrages me.

If I'm just trying to print out "Hello World", why would I use some kind of list and a pointer?

You touched on an example of where Rust simplifies non-GC memory management.

Its nice that there are various ways to track when you are done with pointers (and memory referenced by them) across the code.

I think some of the techniques are very useful. But its taken to an extreme in Rust where you will do anything to avoid GC.

Some of that stuff involving tracking and matching ownership or correspondence across the code would work better outside of a purely sort of one-dimensional textual representation. This is an example that illustrates why textual source code is a legacy.

But it IS text, and often, with Rust, its too complicated, and often not easily applied to typical "systems" programming (which is quite often used to actually mean some ordinary types of user applications, or programs that do the same thing).

Personally I think Rust could maintain a good portion of its core strength while losing about half of its complexity.

Also, in terms of an introduction it would be nice to see some real useful "systems programming" examples where the core memory tracking and other capabilities make Rust stand out. Hello World isn't a good example of this.

We want the compiler to be smart and be able to avoid collecting things at runtime when possible and practical, and for the programmer to be able to effectively indicate corresponding data so the compiler will know when it should be deallocated. However, we also need the code to be clear and concise and to avoid making the programmer do routine work when its not necessary.

<comment><AUTHOR>
       > while avoiding about half of its complexity.

If you know how to do this, while staying within Rust's design goals, we'd love to hear about it. I think Rust is no more complex than the problem demands, but I'm biased!

</comment></comment><comment><USER30> Like the writing style and the detailed play-by-play traces. A small tweak that would help to make it easier to read would be to visually highlight what changed from one memory snapshot to the next.

</comment><comment><USER31> That example of aliasing - is it possible to write such thing in Go? Will Go compiler eat it or will not compile? Just interesting, how Go behaves in comparison to Rust, as another modern language.

<comment><USER32> You can have aliasing pointers in go; see [https://gobyexample.com/mutexes](https://gobyexample.com/mutexes) for how you have to explicitly lock to update the target without undefined behaviour.

However, since it's a GC, it's probably not possible to have a pointer that refers to a memory location that doesn't exist, because having a pointer to a memory location is _by definition_ what keeps it from being free'd by the GC.

<comment><USER31> thanks. but time between 2 lines of code can be not enough for GC to be called to free first address. Maybe they just control it on language level.

</comment></comment></comment><comment><USER21> What I feel is lacking in rust tutorials is when it's ok to use unsafe code. It's very hard to get a feel for that.

<comment><USER33> Huon (dbaupp) has a nice overview: [http://huonw.github.io/blog/2014/07/what- does-rusts-unsafe-m...](http://huonw.github.io/blog/2014/07/what-does-rusts- unsafe-mean/)

</comment></comment><comment><USER34> > You highlight lines four three six.

I guess there is a typo and should be "four through six" instead.

</comment><comment><USER35> Like it, but contains some typos.

becuase

langauges

ownerhsip

</comment><comment><USER36> Alternatively, my video introduction to Rust should be live soon: [https://www.youtube.com/user/DevFactor](https://www.youtube.com/user/DevFactor) Always great to have a few viewpoints.

I 'kudos'ed your post though - because I thought it was very nicely written!

<comment><USER37> I'd appreciate it if you provided a bare link to your channel instead of one that pops up a Subscribe modal.

<comment><USER36> Of course, my bad!</comment></comment></comment>


Ask HN: Now that Giphy sold, what can RightGIF do for you? - <AUTHOR> Hi folks, I'm Alan, one of the founders of RightGIF. We originally built RightGIF as an alternative to Giphy in our own Slack teams. It quickly took off and became one of the top "social & fun" apps in the Slack marketplace (behind only Giphy itself which was the defacto first-party GIF app at the time).
It got very expensive for us to run, and we very nearly sold the app early on, but decided to keep hold of it and just add some little premium features to keep it afloat. Since then it's been running pretty close to break even. We kept it because we always had the intention of one day picking it up and getting serious about it.
Now that both Tenor (GIF Keyboard) and Giphy have sold to Google and Facebook respectively, we feel like it might be time to get serious.
What I'd love to know from the HN community is: a) do you have privacy concerns about Giphy/Facebook tracking? b) what platforms would we need to support to get you onboard with RightGIF c) are there app developers out there that would make use of our API if we made it public?
Thanks heaps! <comment><USER2> I've always been curious as to how Giphy/other GIF providers are allowed to monetize on what is basically often snippets of copyrighted material.

Our app uses the Giphy API. Not having animated GIFs meant a few of our users would eventually leave or move to platforms that do have them.

After about a year of usage, we've been relatively happy with it. Our app is PG so we need to make sure all the GIFs sent are completely PG (otherwise users blame us rather than Giphy). Not sure if your API already has the tech to do this. Giphy was pretty good at it, and we only once got a report of a porn-like GIF.

That said:

a. Yes. FB SDK was already relatively sneakier than we had expected and we would have done away with it a while ago if we didn't have so many users "signed in with facebook"

b. I assume it's just a regular HTTP request but you probably want to have Kotlin/Swift/etc

c. We might move to it IF it turned out that the privacy issue was actually real and not just our own assumption.

</comment><comment><USER3> The reason why Facebook bought Giphy is not the Gifs themselves, it's the data. So I would say the privacy of search data and context would be the number one concern for anyone. It's pretty hard to find the balance between privacy, trending content, and relatable content, but it's for you to tune the knobs.

Also, if you release the API, I'd say making it a drop-in replacement for Giphy would increase the adoption. S3-compatible storage options, or Fixer- compatible APIs, etc are examples and they can help reduce the friction.

<comment><AUTHOR> Yeah, privacy for us has always been #1. It means we will need to monetise, but all indications are that teams are willing to pay a small amount for that privacy. We have the benefit of not wanting to get rich.

</comment></comment><comment><USER4> Well Gifs in the context of Twitter and messaging apps are almost always a _reaction_ to something said.

Even now I find some of the labelling of Tenor (GIF Keyboard) and Giphy to be lacking. Which makes it hard to find an appropriate reaction GIF.

Better search, categories and recommendations would probably be a good addition.

Maybe a merge tool too, to combine too gifs for the perfect reaction GIF....

<comment><USER4> Just thought of another feature.

GIFs are highly emotional (in most cases) I think a good UX feature would be to quickly describe a complex emotion by clicking through emotion recommendations, and adding them to a tag list which could find you matching GIFs

(Happy), (Nervous), (Scared)

(Happy), (Hungry), (Sleepy)

(Angry), (Hungry), (Tired)

This could help find the _perfect reaction GIF_... The possibilities are endless

[http://www.davidhodder.com/wp- content/uploads/2018/10/Emotio...](http://www.davidhodder.com/wp- content/uploads/2018/10/Emotion-Feeling-Wheel-1.jpg)

</comment></comment><comment><USER5> I definitely think there would developers ready to use your API.

Hope you will expand beyond Slack. We use RocketChat. But I assume the other platforms will be a priority first for you.

Good luck growing the company by the way and offering a non-FAANG alternative.

<comment><AUTHOR> Thank you! My hope is to be able to support as many platforms as we can, or even open up the API in way that allows users to roll their own.

<comment><USER5> What is your email by the way or best way to reach out to?

</comment></comment></comment><comment><USER6> Is there an easy way to filter in RightGIF for "images that will auto-expand in slack and not be too big", I hate guessing in Giphy if my chosen image is gonna be too big to auto-expand.

</comment><comment><USER7> It's not obvious from the demo on your site, will/can you return more than one image for a given phrase?

I bought a really simple (or possibly stupid?) domain that takes advantage of a particular TLD to make a common reactionary phrase, and it returns gifs that match that phrase.

I'd used the Giphy and Tenor APIs and I'd be interested in yours, but without Multiple results it'd defeat the purpose. Also I kind of assume your web site demo is limited to "safe" results, would you make "unsafe" results available via api?

</comment><comment><USER8> I'm curious, I'd love to know more about the business model in this space? What's the revenue model in the GIF business?

</comment><comment><USER9> Considering that there are two other large tech cooperations named Microsoft and Amazon out there, would you sell RightGIF to them? Microsoft will probably be interested because of MS Teams that is currently using Giphy.

Even if you don't want to ultimately sell, you should try to get Microsoft to use your service.

<comment><AUTHOR> I know GIFs are not exactly an "important social good", but I do like the idea of keeping RightGIF independent. We definitely want to integrate with Teams of course, so there will no doubt be conversations to be had there :)

</comment></comment><comment><USER10> a) yes b) Android, MS Teams c) I bet that - obviously!

Also: I'm not a frequent user of GIF apps/keyboards, because gifs load for so long. Did you think about it to preview only every X frame of the GIF (even like 3 frames per gif) cause people usually know what gifs they are looking for (don't have to explore the dataset to look for "the one that seems right"). Maybe it will load them quickly. And if a user does not choose a gif for X sec, it loads all of the frames or next gifs?

</comment><comment><USER5> What happened to gitr.io by the way?

<comment><AUTHOR> LOL... I forgot it even existed. It was a hackathon project that never made it past being a hackathon project :) I'm glad someone remembers it though!

</comment></comment><comment> 011-video GIFs sucks. Most popular GIFs are video chunks played in loop. So reverse the process and convert GIF to video. With web app as 011.video for instance you can reduce the file size by a factor of 10 easily, just upload GIF, resize and download WebM video. Even better, for your own website use the original video chunk, play it in loops and make it clickable with HTML 5.

<comment><USER11> Don't get tricked by the "GIF" names. Ex. Giphy will only use GIF if videos do not work. They mostly use video formats.

I assume it's the same for RightGIF?</comment></comment>


Ask HN: Do you remember Library Class? - <AUTHOR> Part of the rotation ( industrial arts, home ec, keyboarding (music))
Learning the card catalogue, Dewey decimal system, how to use microfiche, film strips, difference between non fiction and fiction
And asking why would anyone want to be a librarian <comment><USER2> Never had an actual class for this but in elementary school we would learn how to use the card catalog and the dewey decimal system and all that. We maybe went down a few times and that was it.

</comment><comment><USER3> i remember the class, but not a lot of its content.

oddly enough we still use microfiche in my industry (banking, although its phasing out as images mature)</comment>


Why Fred Wilson Is Wrong On Android vs. iPhone - <AUTHOR> http://www.stangeek.com/why-fred-wilson-is-wrong-on-android-vs-iphone

<comment><USER2> _Now the question isn't: which OS is installed on as many handsets as possible, but which OS/phone has the highest probability to be owned by a fashionista (hint: iPhone) ? Same question about gaming: on which platform do you find the most "hardcore" (i.e. willing to pay a significant amount) gamers (hint: iPhone) ? And for a productivity app ? (hint: blackberry - at least for now). Last question: where do you find most influencers (word of mouth is important for social apps I'm told): iPhone or Android ?_

The problem with this article is that it's countering Fred's post (which used statistics) with assumptions and guesses. Sure, there's a chart at the end with some data about income reported by owners of different phones. However, the meat of the author's argument is based on assumptions (presented as smug "hints") about which platform has more fashionistas, hardcore gamers, and people willing to pay for a productivity app. Someone else could just as easily write an article smugly hinting that the Android platform has more x, y, and z, and both articles would still be based on assumptions.

</comment><comment><USER3> Maybe there should be a poll: Would you actually pay for an android app from the marketplace? I get the impression, from most of my android-wielding friends, that the answer is no. [yes, i know, there is an element of selection bias involved].

<comment><AUTHOR> You might well be right. As you can see from the chart in the blog post, income seems lower for Android owners. Which would imply that, even if the same proportion of users where ready to pay for an app, the market would still be smaller nonetheless...</comment></comment>


Quantum steampunk: 19th-century science meets technology of today - <AUTHOR> https://www.scientificamerican.com/article/quantum-steampunk-19th-century-science-meets-technology-of-today/ <comment><USER2> TL;DR: Describing "quantum engines" requires a quantization of classical thermodynamics.</comment>


The myth of the criminal immigrant - <AUTHOR> https://www.themarshallproject.org/2018/03/30/the-myth-of-the-criminal-immigrant <comment><USER2> But immigrants talk different languages and look funny, this frightens me and I need protection</comment>


Show HN: In memory of Bob Ross, a simple painting generator, Gogh - <AUTHOR> http://ngokevin.github.com/gogh/ Currently features the sky, the ground, and a tree.<p>Happy little clouds are in progress. <comment><USER2> Very nice. I was sad to see it stop when it had done the tree.

The Joy of Painting is great (Bob Ross Incorporated, not so much). I don't think I'd ever hang one of those quaint images on a wall. But the quick techniques to achieve a certain effect are fascinating, at least to an ignoramus like me, e.g. pushing down with a certain brush to get tree branches, or swooshing down on previously drawn stuff to create reflections on water.

Incidentally, I've always thought there was something almost algorithmic to it: the motives themselves were really formulaic, and the techniques reminded me of certain Photoshop tools and brush effects. The submission is a fantastic start, but I think you could go much farther than that.

<comment><AUTHOR> Thanks for the encouragement! I'm still going to keep going, but I wanted to submit it close to Bob Ross's anniversary. I was planning to do mountains next.

</comment></comment><comment><USER3> It's beautiful.

And it's further a demonstration of how magical Bob Ross was; without his narration, it's just an insipid landscape, if the clouds are not happy and little, and the left cloud does not have the right cloud as a friend.

</comment><comment><USER4> This is absolutely fantastic!

It would be interesting to expand this to allow user control - a bunch of procedural high level brushes.

The goal would be to get someone who can't draw able to drastically influence the output, but still make the result look good.

Do you mind if I pinch the idea and see what I can come up with in that direction?

<comment><AUTHOR> Definitely, go for it. That's what GitHub forks are for right? :)

</comment></comment><comment><USER5> For those interested in tightly-coded procedural graphics, have a look here: [http://pouet.net/top10.php?type=procedural+graphics&plat...](http://pouet.net/top10.php?type=procedural+graphics&platform=any+platform&x=29&y=16)

</comment><comment><USER6> Nice - but needs more happy little clouds :)

<comment><USER7> Or a happy little bird.

</comment></comment><comment><USER8> Are you guys looking at the same picture as I am? What I see is a weak copy of Bret Victors landscape generator with horrible colours and MSPaint-like strokes.

I mean it's nice to have such a thing on your CV, but why post it to HN? (and why upvote it?)

<comment><USER9> Could you link to Bret Victor's generator, please?

</comment></comment><comment><USER10> totally reminds me of [http://www.schlussdienst.net/html/canvas- flowers/canvas-flow...](http://www.schlussdienst.net/html/canvas- flowers/canvas-flowers.html)

</comment><comment><USER11> I'm going to fork this and make a new version in memory of Vincent van Gogh, which I'll call Bobross.

<comment><AUTHOR> Well played.

</comment></comment><comment><USER12> This is gorgeous.

Though, if in memory of Bob Ross, why is it named after Gogh?

<comment><USER13> The brushstrokes are more in Van Gogh's style. (not the author)

</comment></comment><comment><USER14> You might also appreciate "Automated Landscape Painting in the Style of Bob Ross"

<http://www.cgl.uwaterloo.ca/poster/alex_NPAR.pdf>

The full paper is behind a membership wall here <https://diglib.eg.org> but you can read the first page here

[https://diglib.eg.org/EG/DL/WS/COMPAESTH/COMPAESTH09/115-122...](https://diglib.eg.org/EG/DL/WS/COMPAESTH/COMPAESTH09/115-122.pdf.abstract.pdf)

</comment><comment><USER15> Snow-capped mountains :)

</comment><comment><USER16> Fun, thanks for posting.

If this puts anyone in the mood to receive some Bob Ross affirmations, I really enjoyed PBS's Bob Ross remix made earlier this year: <http://www.youtube.com/watch?v=YLO7tCdBVrA>

</comment><comment><USER7> Cute: "on the second day, ngokevin built the sky [ngokevin]"

</comment><comment><USER17> Happy little trees :)

</comment><comment><USER18> This is really cool. How apropos that I just last night started reading PG's book "Hackers & Painters"!

</comment><comment><USER19> Where are you based? If you're in NYC or Berlin, you should present this at Hack And Tell! It's great!

<comment><AUTHOR> In Oregon. If I was in NYC, I'm not too sure if I would venture out into that weather.

</comment></comment><comment><USER20> That made my day -- seeing JavaScript draw me a happy little tree.

</comment><comment><USER21> Beautiful

</comment><comment><USER22> I may use these generated pictures as backgrounds for slide presentations, so it would be nice to hear if the author is fine with that. What license is the resulting picture subject to?

<comment><USER23> I am not the creator, but in the spirit of Bob Ross the only natural thing would be to liberate it: "It's your world" :-)</comment></comment>


Making Peace with Allison - <AUTHOR> http://www.whattofix.com/blog/archives/2011/01/making-peace-wi.php

<comment><USER2> Did you lift her pictures off the internet or did you have her approval? From the comments it sounds like you did not have her approval.</comment>


Perfect timing: a bug that only shows up in the first 250ms of a day - <AUTHOR> http://labs.qt.nokia.com/2011/04/09/perfect-timing/ <comment><USER2> The architecture/design part of this article sounded a bit odd. For the sake of 'purity of design' or something like that he decided to eschew constructors, but then it turns out that an un-initialized timer is not useful... which to me is the classic example of when you _do_ provide a no- args constructor with a smart default...?

These sorts of designers annoy me. They've disappeared too far up their own backsides for the sake of some arbitrary aesthetic. Moreover by leaving traps like this in their own code they always get out of their depth, and it's the pragmatists like me who have to go in after them and rescue them.

My rule of thumb when choosing between great art and great pragmatism is to make life easier for 'the next guy'. Because 9 times out of 10 _you're_ the next guy.

<comment><USER3> When I read that part, I thought: there is your problem.

</comment></comment><comment><USER4> Reminds me of the time we had a data encoding bug that only happened when the length of the data was a multiple of 57.

At first it appeared to be random then a colleague noticed the commonality in the lengths of the data that had the problem and after that replicating it and fixing it were relatively straightforward.

<comment><USER5> One of the many interesting bugs that Apache 2 has accumulated workarounds for is one that involves HTTP headers that end with a newline on the 256th or 257th characters.

[http://hi.baidu.com/blog/blog/item/bd01213fd850dfe954e72300....](http://hi.baidu.com/blog/blog/item/bd01213fd850dfe954e72300.html)

</comment></comment><comment><USER6> Time-based bugs are a nightmare to debug but in my opinion the far more insidious side to them is that, even once you've found the bug, there's an easy workaround - just reboot the box! Papering over problems is asking for disaster, as the US armed forces found out:

Patriot Missile Software Problem <http://sydney.edu.au/engineering/it/~alum/patriot_bug.html>

"Ironically, Israeli forces had noticed the anomaly in the Patriot's range gate's predictions in early February 1991, and informed the U.S. Army of the problem. They told the Army that the Patriots suffered a 20% targeting inaccuracy after continuous operation for 8 hours.

Army officials presumed that Patriot users were not running the systems for longer than 8 hours at a time. They suggested if they would be running for continuous periods, they were rebooted regularly (which took around 1 minute and would reset the system clock to zero)."

This is where I part company with the author, when he says:

"If a particular failure happens twice a year in thousands or even millions of runs in that period, you'd be excused if you attributed that to 'the alignment of the planets' and simply went on your merry way."

No. No a thousand times. Whenever you find a problem, any problem, you owe it to yourself to dig until you find the actual cause. If you don't find the cause, I guarantee the cause isn't magically going to become "cosmic rays", and rest assured the problem will come back to haunt you when it combines with other "random" issues in a cataclysmic failure; fate is funny that way.

</comment><comment><USER7> We had a strange bug that only surfaced on the last day of every month. One of our directors asked what we were doing to troubleshoot this bug. I responded that we were a bit more focused on troubleshooting bugs which occurred every day.

</comment><comment><USER8> Bugs in time-based code are great. The most amusing example I've seen was an intermittently-failing automated test case which, I discovered after careful scrutiny of the results database, failed only on Sundays.

There's also the classic time zone unit test "convert this Europe/London timestamp to America/New_York time, verify that it is now 5 hours behind", which, due to Bush's pointless Daylight Saving shift, now fails for two weeks twice a year. Of course, two weeks is _just_ short enough and the bug is _just_ inconsequential enough (the time zone code itself is working correctly, after all, it's the test case that's broken) that the regression goes away before anybody fixes it.

I can only imagine how much otherwise robust code flips its lid when presented with, for example, a leap second. It's the number one argument for the use of mock objects in testing.

<comment><USER9> "Bush's pointless Daylight Saving shift"

?

Staunch Democrat though I may be, how is the Daylight Savings shift Bush's fault?

<comment><USER10> One of the last things he did in office was move it 2 weeks earlier. Canada followed along and now North America is out of sync with most other countries.

<comment><USER11> So just use UTC and get on with your life?

<comment><USER10> I'd prefer to just get rid of DST.

</comment></comment></comment></comment></comment><comment><USER12> Fantastic work! But bug finds like this make me cringe. You can guarantee that your client, or your client's boss, only tests your app out when they get home - at midnight. And you're reduced to a mumbling, sobbing mess as you tear down and rebuild your code yet again.</comment>


The Big 4 wireless carriers have created bottleneck to innovation that keeps coolest phone features unavailable to users - <AUTHOR> http://www.forbes.com/2007/06/08/wireless-fcc-auction-tech-intel-cx_bc_0611wireless.html <comment><USER2> OK everyone, calm down.

Let me explain what these internet companies are asking for. Essentially they want the telecoms to pay us, the American Taxpayers, BILLIONS for access to wireless spectrum. Subsequently, they want these telecoms to be obliged to let them use the same wireless spectrum for free.

Did I mention that the wireless spectrum is OURS? That it is the sole property of the American Citizenry?

Start standing up for your rights people. Either EVERYONE pays US for access to OUR spectrum, or NO ONE does. Look at it this way, on average, many would say a black guy is more cool than any other guy. That said, if one comes into MY store and wants MY product, he will pay the same price as everyone else. Any other method of operating is known as DISCRIMINATION. If Google wants to use OUR spectrum, they are welcome to bid on it like everyone else.

But come here Google . . . a little closer I have to tell you a secret. WE are probably going to charge you a good deal more for usage rights to that spectrum than the telecoms want to charge you to sub-lease it. It's because our government needs the money and . . . Oh who am I kidding . . . I just love sticking it to huge companies like yours. I don't care what the other reasons are. By the way, we also have laws that limit your ability to pass those costs on to the consumers, typically us. That's because WE want to be able to access the spectrum as close to free as possible, even after we sell the usage rights to it. You know why? That's right . . . because it is OUR SPECTRUM!

I apologize for this rant. It just seems to me that when a company like F@#K!^& GOOGLE is whining about something like this, the cult of victimization in this nation has officially reached its farcical zenith. The people who started that company, AND the early employees for that matter, have more money than 99.9999999% of us. Yet STILL, they want us to give them even more of the few of our resources that they don't already own for FREE!!!

I have to stop working Sundays...

<comment><USER3> That wasn't the proposal in the article. It was for a _segment_ of the wireless spectrum to be auctioned off with the restriction that it be open to any device that meets certain specifications. The big-4 wireless carriers can keep their allotted bands; this is a new part of the electromagnetic spectrum that is scheduled to be auctioned off shortly anyway.

If the wireless spectrum is OURS (as in, the U.S. peoples'), it makes sense that we can restrict its usage in whatever way would benefit the people most. It also makes sense that one such way would be to restrict its usage so that the buyer cannot restrict other firms' usage of it.

It's essentially an easement. You know what an easement is, right: the owner of the property sells off certain rights and restrictions to a third-party. For example, power companies will buy an easement to run high-tension lines over a field. Wealthy individuals will sell an easement stating that their land will become conservation land after their death, and the owner will be prohibited from developing certain areas. In this case, the government is giving an easement for open-access to the general public, and selling off the remaining rights to that portion the EM spectrum to the highest bidder.

There is no economic reason why this chunk would sell for higher than the existing telecoms' slices. Its usage rights are restricted: generally, an easement lowers the value of the remaining property rights, since you can do less with it. Also, if you read the article, you'll notice that it's being _auctioned_ off, which means the government isn't setting a price, it's selling it to the highest bidder, who will presumably be responsible for developing the network and putting up cell towers.

Actually, if I had a few billion dollars in funding and a plan for putting up cell towers more cheaply than the established carriers, I'd buy it. This could be a game-changer on the same order as Intel's invention of the microprocessor. Before Intel, the minicomputer field was much like the wireless field, with many vertically-integrated carriers stifling innovation. Because Intel (and Microsoft) decided to focus only on one area and relentlessly lower costs, letting others innovate in the app sphere, the PC market exploded. We all know how it worked out for Intel and Microsoft...

Even if the government doesn't grant this easement, a savvy investor should swoop in and make that portion of the spectrum open-access anyway. There's potentially a _massive_ market there. Too bad I don't have a billion dollars...

<comment><USER2> Alright, firstly if you read my post I said Google is free to BID on the spectrum like everyone else. It is my hope that these bids run into the BILLIONS, we should get our cut.

Secondly, an easement brings down the price for the reasons you outlined. However, there will be NO restrictions on HOW the winners use this spectrum. Only a provision that they let other cheap bastards who are not paying us use the spectrum as well, for FREE. Now as long as EVERYONE pays I am happy. Yet when ONLY the telecoms have to pay, and the internet companies ride for free, the American People are losing money. I spend the summers in Paris, and I can tell you that the American People can ill afford to give things away for free. 1 Euro is about US$1.34 right now.

The fact that the price would be lower for this spectrum is EXACTLY what INCENSES me. These people will make BILLIONS, and you want us to let them weasel out of the spectrum fees. They already have a myriad of different options for weaseling out of our ability to tax them on the back end. With all due respect, sir, we must agree to disagree.

To everyone else, believe me, I'm wealthy enough. If the majority of us wish to continue to give more and more to the wealthy in exchange for less and less, then that is democracy and I will go along with it. It will benefit me after all. I am simply stating my belief that it is contrary to the interests of other social classes.</comment></comment></comment>