Slow email replies cause serious anxiety - <AUTHOR> http://www.bbc.com/capital/story/20161103-your-slow-email-replies-are-causing-serious-anxiety <comment><USER2> That seems crazy. Honestly, mail is my main communication medium exactly _because_ you cannot see when I read the message and because of the implied asynchronous exchange.

If the person on the other end is feeling anxious about that exchange I

a) have no sympathies, none at all

b) feel that they don't understand the medium they're using (as confirmed by the "I could always pick up the phone" line at the end of the article)

I'm trying hard to suppress a "Booohoooo" reply here. Persons that concerned about exchanges (and IMs make this that much harder - I see so many passive aggressive "And?"/"You read it, what do you think?" messages around me, because people assume that "Saw the message" equals "Has time and incentives to answer me right this very moment") need to see a doctor. If you can describe this as anxiety, you might need help.

<comment><USER3> That's why I love chatting with Wire, there's no "seen" status by design and can completely avoid this kind of mental BS.

<comment><USER4> You can use this [https://chrome.google.com/webstore/detail/facesnoop/kebmejpc...](https://chrome.google.com/webstore/detail/facesnoop/kebmejpcciehlicgipgfinbgdbedeoag?hl=en) to disable Facebook's "Seen" function if you want

FD: I made it

</comment></comment></comment><comment><USER5> Here's the strategy that one of my professors uses and that he explained to me some time ago: While he reads and replies to incoming emails througout the day, he set up his mail server (or email client) to only send out his replies once a day, namely at 4.30am. That way,

1) correspondents are prevented from using email as chat, i.e. from burning a lot of his time 2) people write more result-oriented emails, knowing they will have to wait for his response for a day 3) the total volume of emails reaching him decreased because a lot of the issues people (want to) email him about often solve themselves within a day, so people don't bother emailing him about them anymore, knowing that he won't be able to help them in time.

<comment><USER6> Or use the strategy that one of my professors used: refuse to get a school email address and all the associated computer accounts and hence be completely incapable of doing most paperwork. The important stuff they'd find a way to get him to do anyway.

Note: tenure may be required. Predating the email system helps, too.

<comment><USER5> Well, not using email at all is pretty much impossible, considering how many committees said professor is in and how many students he's handling. It's also not his goal because he does like working with them and participating and so on. It's just that he was looking for a more time-effective method to do so.

<comment><USER6> He had a department email, but not the school-wide system account/email.

</comment></comment></comment></comment><comment><USER7> I am completely the opposite. I get anxiety over e-mails that I've personally left unattended in my inbox, because I didn't have time to handle them yet. Damn it, another e-mail I have to "mark as unread"...

If I hit "send", and the ball is in someone else's court, then it's usually somewhat of a relief.

<comment><USER8> I'm like this too. I can't stand unread email.

</comment></comment><comment><USER9> > For starters, you should be clear on when they expect a response back

If only recruiters and hiring managers took this seriously! They've been the worst communicators I've ever experienced in my professional life--as the applicant. I'm cool with ignorance of an initial application. That's normal. It's just after I interview with a company 2 or 3 times for a position and then they ignore my communication that I become quite annoyed.

Example 1: I am currently waiting on a response to a second in-person interview I had with a number of people at company X. I was told that I would "hear back next week" from the hiring manager. 2 weeks later, I sent an email to check in. 1 week later, still no response.

Example 2: A while back with the much more well-known company Y I was told that I would "receive feedback soon" by a recruiter after they had flown me out and had dedicated basically a half-day worth of interviews for me with their team. I followed-up 1 week later and received a message that "the team has been busy" and that they'll "get back to [me] next week." I sent another email checking in 2 weeks later. Ignored. I tried again 2 or 3 weeks later after that. Ignored again. And just because I still had the recruiter's email address, I followed-up 2 months later and finally got an email that the position had actually been removed.

<comment><USER10> We will get back to you = buzz off. Just don't expect a response and keep looking for other jobs. Eventually someone will respond. If they get back to you when you already found a job tell them you'll get back to them in two weeks.

</comment></comment><comment><USER11> I ran a support organization. Maybe the most effective policy we implemented for user satisfaction was that a human, not a machine, responded immediately to every email, even if only to say 'we've received your message and we'll get back to you at time X'.

Until you respond, the sender doesn't know if you received it or not (maybe there was a server or network problem on one end or the other; maybe it went into your spam folder), if you noticed it or not (maybe it was overlooked?), if you read it or not (too busy? blowing me off? mad at me? I'm not important enough?), and when you'll get around to doing something (should I count on it happening today? tomorrow? next week or month? ever?). They wonder if they should send another message (too pushy? but if the recipient didn't see it for one of the above reasons, sooner is better than later). They are operating in the dark unknown, and imagine all sorts of things. Effectively, you've set no expectations for them.

I know that, because I noticed how I felt and thought when I was on the other end. Our customers seemed much happier, even if response times (an actual response to their problem, not just a confirmation of receipt) and service completion times didn't change.

<comment><USER12> Interesting. I do IT infrastructure support. I generally respond after I've completed the task but this makes me think that I should reply to their email immediately with something like, "I'm looking into this."

<comment><USER13> I managed an IT team for awhile. While you may be working diligently on the task, the 'client' (whoever that is) has no idea that any sort of action has even started, which can induce a lot of anxiety, depending on the situation. You'll have much happier customers if you keep them in the loop early.

It doesn't have to be arduous. The four words you wrote above are enough. Or, "Hi Bob, I'm on another task at the moment, but I should be able to look into this in a couple of hours. Will be in touch." has a significant calming effect, and will often buy you extra time.

Of course, Bob might just say "this can't wait a couple of hours" but that's a separate chapter in human relations. :)

</comment></comment></comment><comment><USER14> All my emails are on a one hour tape delay, to account for global lunch breaks in time zones around the world.

Somewhere in time and space, people are trying eat lunch right now.

Even SMS gets a tape delay for the first response. What if my phone was on vibrate in my coat pocket, hanging in the closet? After that first response, you'll know I have it in hand, so I'll make with the snappy replies, since I trusted you with my phone number to begin with.

Chats? The window was minimized. What do you want from me? Blood?

Emails may or may not enjoy 24 hour response times. I don't check all of my email addresses on a daily basis. Work emails are starkly divided from personal emails, for legal reasons regarding domain names (DNS) and bare metal server locations and territorial jurisdiction. Some animals are more equal than others.

</comment><comment><USER15> I've found if I reply too quickly it often ends up creating more messages than if I just sit on things for a while. People often seem to resolve their own problems if you give them some time.

If they have a problem with that then that really is their problem, not mine.

<comment><USER16> This. Not sure why 'Send in x min/hours/point_in_future' isn't a more common feature of communication software.

<comment><USER17> I use boomerang in gmail specifically for this.

<comment><USER16> I'm aware of it, and I can't believe such a simple service is a paid add on.

</comment></comment></comment></comment><comment> http-teapot I've never been as busy as the past 4 months. I don't reply to emails that requires lengthy text. If I can reply by "Yes", "No" or any of the derivatives then you'll get an answer from me.

If you have a problem, what do you think is the solution? If you need something, what exactly do you need? You want to contact me, what's your phone number and when are you available? You don't feel great, why? How can we solve the problem?

It's super important to not hurt people feelings and speak right and that takes a lot of my time (especially as a non-native English speaker.)

On the other end I commit to read every emails.

<comment><USER18> After 20 years of working I've learned: answer quickly (to the emails that you intend to reply to) even if the only thing you can say is "I have read this and will get back to you".

I used to fuzz and wait until I had the ultimate, perfect reply.. usually like 12-48 hours later. Turns out that is the wrong approach - for the reasons outlined in this article.

> On the other end I commit to read every emails.

That was my defense too! I iterated it over and over to my team (my bosses would get preferential treatment...), but noone would believe me - unless I responded. People tend not to believe invisible things.

<comment><USER19> This is a good strategy, and even better if you tell them when to expect a proper reply (and then you stick to it). That really helps the sender make plans at their end, and thus reduce their stress.

<comment><USER18> I also, perhaps a little surprising (but not really), found that it reduced my own stress as well.

</comment></comment></comment></comment><comment><USER20> You need to educate your peers that they should not expect immediate response. I am even delaying answers to Skype, Facebook and WhatsApp these days, otherwise people begin to ask you how is the weather in the middle of the night and keep sending ??? when you don't answer...

</comment><comment><USER21> As a partial response to this people have invented a new plage: out of office emails for when I email outside of 9-5 weekdays.

 _I already know_ that people don't work 24/7, I even understand timezones. If I fire off an email, I'm totally cool if they pick pick it up in the morning. But then I get prematurely excited by an "immediate" response which turns out to be just a bot telling me what I already know.

</comment><comment><USER22> What's wrong with a phone call? If we expect immediate feedback we should use more appropriate communication tools.

<comment><USER23> It's all context and the work environment and the habits of the people you're dealing with. Phone calls can potentially be rude and disruptive because effectively you're telling another person that whatever you want in this instant is more important than whatever they're doing, no matter what they're doing. They have to stop everything to deal with the phone call, in the same way as if someone just barged into their office uninvited, sat down, and blindly started talking, ignoring whatever else might have been going on at the time.

In engineering environments, phone calls also tend to be ineffective ways to communicate technical information, whereas email threads (terse or not) preserve the history and context of decision making processes, which can be revisited or cited as needed.

Also, nowadays more and more people simply hate the experience of talking on the phone and would prefer that it didn't even exist in their lives as a communication device. So there's a whole personal preference angle that's independent of the pragmatic/effectiveness angles.

None of which is to say that there's anything wrong with a phone call, just that it really depends on where you work, what you do, who you work with, what they do, etc.

<comment><USER24> That's exactly correct. If your communication is in fact important enough to barge in disruptively and demand their full attention immediately, a phone call is appropriate. If your communication is _not_ that important, then send an email and expect to wait, because they're doing other things. Either it's time-sensitive or it isn't. Either you need an immediate reply, or you don't. Why bother being anxious and nervous about something if it's not time- sensitive? If it's time-sensitive, then just make a call.

Where does this bizarre communication anxiety come from?

<comment><USER25> > Either it's time-sensitive or it isn't. Either you need an immediate reply, > or you don't.

I think part of the problem comes from differing opinions on what is actually "time sensitive". I think a lot of the trouble comes from someone using a time-sensitive communication method (phone, physically coming to your desk) on something the other person doesn't see that way.

I certainly have less empathy for someone that has time-sensitive problems through their own poor planning (aka "Your failure to plan is not my emergency"). Everyone makes mistakes, but some people seem to continually have their own self-created emergency all the time, and it's completely draining.

</comment></comment></comment></comment><comment><USER26> I can see that happening with love letters, certainly when sent over snail mail, but with business mail? That "marketing operations manager" needs help; I don't see why the world would have to accommodate to suit him.

Also: I found that it helps to have a rule in your email client that says "if I am not in the _To:_ field, move this to the folder called _CC_ ".

That is a folder you can safely (1) ignore.

Similarly, one _could_ add a rule "if there are over 3 people in the _To:_ field, move this to the _Read Later_ folder", but that is quite risky.

(1) not quite, as long threads may evolve to contain questions for you without people adjusting the list of addressees, but that's the fault of the senders.

<comment><USER27> Good suggestions, might use myself. Also, my favorite rule is 'discard emails with empty subject'. I'm teaching an university class, and the younger generation seems to not understand the ethics of email.

<comment><USER28> Or we in the older generation seem to not understand how the ethics of email are evolving :)

</comment></comment></comment><comment><USER29> This appears to be a human interest story masquerading as a social psychology report:

 _Your slow email replies are causing serious anxiety_

citing one anecdote, then four paragraphs later:

 _there are no statistics or research on just how anxious people get when e-mails go unanswered_

</comment><comment><USER30> I remember a good post about Silicon Valley etiquette, which suggested startup founders to answer on emails within 24 hours. That's a good advice, but sometimes developing product is more important them answer on 101 email.

<comment><USER31> If you are overloaded with email, consider the workflows which are putting so much in your inbox.

</comment></comment><comment><USER32> It could just be me and the way I handle email, but by using something like Yesware you could easily mitigate the anxiety around slow responses. Plus, if I see someone open my email a few days later it's usually a good indication my message is still front of mind and sending a follow up email will usually trigger a faster response.

</comment><comment><USER33> Back in the day the dumb phones had an interesting function - you could use them for synchronous real time voice communication over public switching network. Unless apple removed it with the headphone jack - it is probably still somewhere in the device. We also have an Avogadro constant types and brands of chat apps.

If you use email for time sensitive communication - it is your fault.

</comment><comment><USER34> Your emailing me bullshit that should be handled by IM is causing me anxiety.

I don't check my email more than once every 2-3 hours, assuming that I am actually working and not screwing around in a reactive pattern.

Choosing an appropriate level of communication severity and urgency should really be business 101.</comment>


Most people have no idea what the word hacker means - <AUTHOR> http://www.betabeat.com/2011/07/26/hacked-to-death-how-journalists-are-ruining-the-word-hacker/ <comment><USER2> I find this debate/discussion ("who's _really_ a hacker??") boring and pointless; it's a mainstay of 2600 editor "Emmanuel Goldstein" on the 2600 radio show ( <http://www.2600.com/offthehook/> ). His view is that once you're a malicious criminal (or do something he doesn't like, e.g. Anonymous ddos's) you're not a hacker. "I don't like what you're doing! You're not a _real_ hacker! You give hackers a bad name!"

Now to make myself a hypocrite: One aspect of this phenomenon that I find amusing is how low the bar is set in terms of programming to qualify as a "hacker." e.g. "I hacked together this RoR site over the weekend" makes me think, "You used a popular, well documented website building framework for it's intended purpose... how exactly is this hacking?" "I hacked together a cake this weekend; even hacked my own cream cheese frosting!" People (like myself) who would once have had to settle for a more boring title like "software engineer" or "computer scientists" are all "hackers" now. :p /my 2¢

<comment><USER3> >"I hacked together this RoR site over the weekend" makes me think, "You used a popular, well documented website building framework for it's intended purpose... how exactly is this hacking?"

It's a _third_ sense of the word, meaning something like "put together without a plan, by trying things until they worked". When someone says "I hacked together this program", they mean "I threw code at it, and now it seems to do what I want".

<comment><USER4> Related:

"This is a bit of hack" to describe a solution that is very fragile and subject to breaking, or just ignores good practices.

Technically, you could argue that this is in fact the original usage, as the solution's fragility typically is due to ignoring the conventional semantics and exploiting the actual underlying implementation of something.

</comment></comment></comment><comment><USER5> Most people have a different primary definition of the word "hacker" than the author, in other words.

Most people know exactly what the word "hacker" means within their respective social circles.

It seems almost bizarrely religious to me for someone to say something to the effect of, "the way most people use a word is not the same as my own way or its origin, therefore most people ought to change."

</comment><comment><USER6> _In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that._

        -- Linus Torvalds

<comment><USER7> That's just wrong :(.

<comment><USER8> If your goal in speaking is to communicate something to the listener, then it's helpful to use terms in ways that will make sense to the listener.

How is that wrong?

<comment><USER9> He's helping himself by disassociating himself from the community that supports him. That's a prisoner's-dilemma defection: if everyone is afraid to acknowledge being a hacker when they're talking to journalists, journalists will only ever learn the criminal definition.

</comment></comment></comment></comment><comment><USER10> "But typing the default password "1111" into the voicemail box of a murdered girl is not hacking."

Actually, technically, it is. It just so happened that it was really, really easy.

<comment><USER2> Ironically the same Kevin Mitnick who declared using default passwords "not hacking" gave a talk at HOPE <http://thenexthope.org/> about his adventures avoiding law enforcement in which social engineering played a __central __role. Is lying to someone on the phone to get a password "hacking?" Maybe, maybe not, but he would have been unable to complete his goals without those crucial soft skills.

Perhaps password guessing and SQLi is "script kiddie stuff" but it makes me think of a "skilled thief" who scales a building and deftly opens a locked window 3 stories up, while a less experienced accomplice tries the back door and finds it unlocked. It's silly to condemn someone for using a simple method if that method is effective.

EDIT: Kevin Mitnick is cool guy, I don't mean to criticize him.

<comment><USER11> I think social hacking is far harder than trying to find vulnerabilities in a public server. It requires a whole different set of skills -- and I don't view it as being a "soft skill".

<comment><USER12> Yeah, right. Social Engineering is much easier than gaining access through some 0-day attack you have devised yourself, or even finding some working skiddie method (when dealing with a specific target). For one thing, you don't actually need any actual skill, you just need to be a good liar and have a good story. That's not skills, it's just a sociopathic trait some people are born with.

Kevin Mitnick was a social engineer primarily.[[https://secure.wikimedia.org/wikipedia/en/wiki/Kevin_Mitnick...](https://secure.wikimedia.org/wikipedia/en/wiki/Kevin_Mitnick#Computer_hacking)] Thus, him calling anyone 'not a real hacker' as in the context presented in the article is ironic.

</comment></comment></comment></comment><comment><USER13> My acid test for finding out the mainstream definition of a word is to ask my parents (50-ish but relatively tech-savvy).

In this case hacker means someone who tries to steal your shit by breaking into their computer with viruses.

</comment><comment><USER14> Since we're talking about language use, this quote from Kevin Mitnik:

"What News Corp. did, guess pin codes, spoofing voicemails, that is amateur script kiddie stuff."

Is itself kind of interesting, as there's no use of computer scripting languages at all here. He's using "script kiddie" to mean not "someone who uses pre-written scripts to break into computer systems and then boasts of their skills" but rather "someone whose skills I don't respect."

</comment><comment><USER15> I find this to be a silly discussion. Word have multiple meanings, words are confusing and ambiguous, people are confused and ambiguous. But somehow we muddle through, despite different people assigning different meanings to "hacker." I really just don't care about this.

Then again, I consider the meaning of "hacker" to include both the "amateur script kiddie" types AND people like Peter Norvig, Gerald Sussman, and Rob Pike. It's just a matter of degree and of focus, with context to provide illumination.

</comment><comment><USER16> Maybe this is nitpicking, but did the author this article do zero fact- checking?

>Mr. Mitnick, who ... is publishing his first book in August...

Er... Following the link to his "first book" leads to Mr. Mitnick's website, whose products page lists his... other books...

Not to mention the well-known tech writer Stevy Levy. :-)

</comment><comment><USER17> If your favorite word has been co-opted, then make up a new word.

<comment><USER18> people tried cracker vs hacker, but it never caught on.

Then techies reclaimed hacker as a positive, even if the media doesn't uses it another way.

Now there is hacker, the compliment among engineers, and hacker, the computer criminal in the press.

<comment><USER19> I have thought a lot about this and think "computer ninja" is our best option.

<comment><USER20> Oh no not that please. It sounds so cheesy and cartoonish.

<comment><USER21> Well at least the bad guys can be 'computer pirates' and we can debate which is better pirates or ninjas. And if we somehow managed to get the pirate vs ninja meme into public debate then that would be a very clever hack indeed.

<comment><USER20> Thieves versus robbers, sounds like.

</comment></comment></comment></comment></comment></comment><comment><USER22> "A hack" = a quick and dirty fix to some code to make it do something extra as required by some non-technical manager

"Hacking" = trying out different random changes to a codebase until you stumble on the one that does what you want

Those are the definitions (from 1980's Australia/NZ) that stick in my brain, despite being exposed to the "new", more positive, definition from Hacker News.

</comment><comment><USER23> Hackers have been complaining about that since at least the mid-seventies. Yes, I was there.

<comment><USER24> Yes... this is very, very old news.

<comment><USER25> The debate is very old. But the explosion of news coverage around the word hacker has happened in the last three years.

</comment></comment></comment><comment><USER21> So here is a sad prediction, we'll get to the point where we start calling it 'the h word' and technical people will call each other hackers and laugh but if some non-technical type calls someone a hacker, well that will be completely unacceptable.

And while you think "OMG did he just compare calling someone a hacker to the scourge of racism that we have yet to purge ourselves from?" Yes, I did. You see at some point I suspect it will become, from a non-technical person, a vicious form of character smear to insinuate that a technical person uses their skills to steal from society. And these 'technists' if you will, will arise from a population that is afraid because they depend heavily on technology in their day to day lives and yet they don't understand it, and they are at the mercy of people who _do_ understand it, and that makes them angry because for some, they will feel inferior. And folks who are angry and afraid lash out in vicious and brutal ways to try to salve that fear and anger.

I've tried for years to split the meaning by using 'cracker' vs 'hacker' or simply 'criminal' but to no avail.

</comment><comment><USER26> I'm a Hacker and an Engineer. I'll be damned if I stop using either title just because they were sullied by criminals, confused by the press, or misunderstood by the public.

[Late Edit] I was rather suprised by the implication that the term hacker came from the M.I.T. model rail club. As a model railroader I've never heard the term used in the community. Bash (ie: kitbash) is way more popular.

<comment><USER27> They also originated a bunch of other words, like using foo as a metasyntactic variable. <http://www.catb.org/jargon/html/T/TMRC.html>

<comment><USER26> Interesting. Thanks. I really should read Levy's book one of these days... I've only got three copies of it.

<comment><USER28> You are a model railroader and software engineer who vehemently defends his identity as a hacker, and you own three unread copies of _Hackers_?

s/will wish I had done it years ago when I/should/

<comment><USER26> Valid point. Considering two of those three copies are electronic, I have increasingly few excuses.... Going to move it up in the rotation.

</comment></comment></comment></comment></comment><comment><USER29> Glad that was cleared up. All this time, I thought a 'hacker' was a navel gazing, media junky who happens to know a bit of ruby on rails and javascript!

</comment><comment><USER30> I occasionally wear a T-shirt indicating "I'm a hacker". It has generated a surprising number of comments from strangers in public places.

<comment><USER31> What kinds of comments?

<comment><USER30> They're usually surprised. Some were faintly rude, others were nicer. My canned reply is that they should understand "hacker" in the MIT sense, and that it's not necessarily related to computer security or even computers in general. They usually lose interest at this point.

The most articulate chat that I had was with someone who asked me if I was into social engineering, and explained that he had read _The Art of Deception_ and found it quite inspiring.

</comment></comment></comment><comment><USER32> <http://en.wikipedia.org/wiki/No_true_scotsman>

</comment><comment><USER33> The term "hacker" has multiple meaning, and the use of hacking to manipulate a phone system is not only valid but was also the original use of the term when it originate at MIT in the 1960s.

<http://imranontech.com/2008/04/01/the-origin-of-hacker/>

</comment><comment><USER34> The best way to define hacking in the positive engineering sense I have ever heard is:

"To make furniture with an ax"

To take tools at hand, oft not ideal for the goal, use them to make the more ideal tools if time allows, then to make something beautiful entirely due to the skill, talent, and/or creativity of the wielder.

</comment><comment><USER35> Unless the title of the article has changed, there's some editorialising going on in the headline here of a type that is usually frowned upon on HN. And the result is, in a sense, completely absurd.

Most people have no idea what the word hacker means _to us_.

</comment><comment><USER36> That's because it's slang. How do you define a "jerk", "mensch", "momma's boy", or "hoopy frood"?

</comment><comment><USER37> Most pedants have hobby horses.</comment>


Ask HN: Have you ever lost focus on your personal project? - <AUTHOR>

I been working on a personal project for almost a year now. Its nothing too complicated, just an online text editor. However recently can't even focus on the project. I really need to get this project working, I want to drop out of school and I plan on using this project to get a full time job(use it as a portfolio). How did you gain back your focus? <comment><USER2> Several things that have worked for me.

1) Exercise, a lot. Put it first, so that you'll actually do it.

2) Eat right. These things, exercise and food, can have a far greater impact on your work than you might realize.

3) Discipline. Show up and put the time in. Force yourself.

4) Pomodoro technique. Commit to yourself that you'll put in 2 solid 45 minute periods per day. Work your way up from there. You need to do it even when you don't feel like it.

5) Get friends who encourage you to be your best. If you don't have friends like that, contact me firstname.lastname@example.com

<comment><USER3> Great advises!

I would add:

\- one more: do it fist time in the morning, i know it is hard, but after 30mins of coding you will feel good about your self end progress.

<comment><USER4> I agree with this so much, waking up early starts the day of on a productive note, and you keep going. Also it clears your mind before you start coding, helped me figure out a lot of problems I couldn't get the night before.

</comment></comment></comment><comment><USER5> Here is how I got my passion, motivation, and ambition back. Let's call it my slump-buster. 1\. Find Inspiration. It could be music, watching a movie about a start-up or some other inspiring story. For me it was listening to Brian Stevens keynote speech from the RedHat Summit on YouTube. If you listen to the past 3 years he makes it clear that software developers and Linux are going to rule the world. Use this as a tool to get you into your command center to get stuff done. 2\. Do not come home from work and go to your command center or computer room. You need time away from the computer to remember what your passionate about. Watch TV, go exercise, spend time with your family, whatever makes you happy. 3\. Go to bed early. When your lying in bed, think about your side projects and what you want to build. Go into detail about the code, UI, technology stack, where your going to host it. This will help you dream in code and get you excited to wake up. 4\. Wake up early. I get up around 3am without an alarm clock now because after dreaming about my passion projects I'm so excited to get up and make things happen. You would be surprised how focused you can be at 3am with no distractions. In the last 6 months since I started this new me I have read over 20 books and wrote several documents for my passion project. 5\. Setup the perfect development workstation. I use my 27 inch mac for development but I also have 3 laptops running Linux. I told myself I was going to setup and learn all the best productivity tools to help me code better/faster. I setup my dotfiles perfectly with all the vim plugins I wanted to use, tmux scripts, and pushed it up to github and synced it to all my workstations. It is such a rush to have everything running perfectly. 6\. Start a ritual or habit and set goals. Document all your ideas for your passion projects in as much detail as possible. Go to Trello or Evernote and document everything. Include pictures, links, sound, video, whatever to help you describe your idea and get yourself motivated. I call mine my 5 year project plan even though it will only take me about a year and a half.

</comment><comment><USER6> Strip the project down to the basics and get a working prototype online. Don't try to develop a fully featured project by waiting until step 10 is finished before launching. Instead, spend a weekend on step 1 and launch the site, then develop step 2, step 3, etc.

This way you and others can use the project as it develops. It's a lot more fun when you can play with a working prototype of your project at any given time, and you have users enjoying the service and requesting features. It's great motivation. Also, if you notice at step 3 or 4 that no one cares about your project, you can toss it in the garbage, move onto the next idea, and be glad you didn't wait until step 10 to launch and waste all that time.

When you bite off too much, the finish line is so far in the distance that you lose all motivation.

</comment><comment><USER7> I think the problem is that your passion is for dropping out of school rather than the project at hand. When I look at coders (or anyone) who has a passion for something they'll do said task even if they're going for hours without sleep or even forget to eat.

Also if the project isn't that complicated how good of a demo can it be to get you this undefined full time job? Honestly finishing school may help you more in the long run (unless what you're doing at school has nothing to do with your career).

</comment><comment><USER8> Many times. Usually I become disheartened at how difficult the project really is to complete. Then I ask myself if the project is really important to me. If I answer yes I try to break it down to the next 3 steps, and just commit to doing those three. Sometimes you need to learn something to make progress. After a few question - recommit - work cycles more will have been done on the project. Then you wind up refactoring!

</comment><comment><USER9> I am also having my personal project alongside my full time job. Yes it is difficult to keep your focus on side project. I use to gain focus during the time i travel back to home from office ( plan all stuff during that period )

</comment><comment><USER10> What you need is discipline.

<comment><AUTHOR> I agree I do need discipline, but is easier said then done. I been reading on how to build discipline.</comment></comment>


Ask HN: What would happen to the internet if Google turned off overnight? - <AUTHOR> <comment><USER2> I can't tell if you're thinking of a plausible situation, or something more Reddit-like, but I'll attempt a plausible response.

If a large enough coronal mass ejection (CME) from the sun delivered a strong electromagnetic pulse (EMP) through the Earth, they'd both cease to exist. Pretty much instantly. But there'd also be no more electricity, so it'd be a frantic effort to figure out what happened to them. Actually, only employees and their families, and stock holders will be wondering what happened to Google. _Everybody_ (except perhaps a small area in and around Pennsylvania) will be wondering what happened to the electricity.

Ironically, that would be a highly interesting technical event to post to Hacker News if it happened... and it actually could.</comment>


GOES-17 Releases 'First Light' Imagery from Its Advanced Baseline Imager - <AUTHOR> https://www.nesdis.noaa.gov/content/goes-17-releases-%E2%80%98first-light%E2%80%99-imagery-its-advanced-baseline-imager-abi <comment><USER2> GOES-16 and GOES-17 are supposed to be identical, barring the cooling issue. Check out these fascinating loop-of-the-days from GOES-16. I'm sure they will be adding GOES-17 soon as well.

[http://rammb.cira.colostate.edu/ramsdis/online/loop_of_the_d...](http://rammb.cira.colostate.edu/ramsdis/online/loop_of_the_day/)

</comment><comment><USER3> I had never noticed just how much cloud-cover there is globally. Wondering if it was just an artifact if the false coloring, I did a search. Turns out that that level of cloud-cover is normal[1]. Fascinating.

[1]: [https://earthobservatory.nasa.gov/GlobalMaps/view.php?d1=MOD...](https://earthobservatory.nasa.gov/GlobalMaps/view.php?d1=MODAL2_M_CLD_FR)

<comment><USER4> One of the primary science justifications for DSCOVR is its ability to measure the total combined reflectivity of Earth, dynamic cloud cover and all.

This albedo as it's called is very important for climate science, and opposition to what climate science tells us about the world was an important part of the Bush administration deciding to not actually launch the finished satellite (the main reason being the overall idea was by Al Gore)[1]

All this is to say: check out these real images of the entire Earth [https://epic.gsfc.nasa.gov/](https://epic.gsfc.nasa.gov/)

[1]: [https://www.airspacemag.com/space/al-gores- satellite-1809521...](https://www.airspacemag.com/space/al-gores- satellite-180952132/)

<comment><USER3> > albedo

That's exactly why I found this so fascinating. I know that the ice caps are extremely important for slowing climate change (due to their albedo, being completely white). I had no idea that clouds were so prevalent. My initial thoughts on seeing that image were "wow, that's a lot of albedo, has climate change improved cloud coverage?" A directly counteracting force to the most dangerous GHG (water vapor). Turns out maybe not? We don't have industrial age data in this, so we can't tell for certain - but maybe (likely not) there is a glimmer of hope.

Thanks for the additional information, either way.

<comment><USER5> Clouds work both ways: They reflect short-wave visible radiation back into space, but they also send long-wave thermal radiation back to the ground and keep it warmer (compare your experience with cloudless nights to ones with clouds).

So far it looks like high clouds have a cooling effect and low clouds have a warming effect. We are not sure yet which clouds will increase more (this may not be up-to-date or might be known soon) but we expect more clouds in general in a warmer climate.

<comment><USER6> You have it backwards; the cirriform clouds are mostly transparent to visible but absorb and re-emit IR effectively (cloud greenhouse effect). Low clouds tend to have a very high albedo, hence effectively reflect incoming solar radiation, like ice/snow.

<comment><USER5> Indeed, thanks for the correction!

</comment></comment></comment></comment></comment></comment><comment><USER7> Unfortunately, the cooling system on this instrument isn't working as expected. We've got the visible spectrum, but not some of the long infrared wavelengths.

<comment><USER8> I wonder if this can be mitigated with software processing

Still, I wonder what kind of information can be gathered by long infrared here. Heat reflection/balance on the Earth? Climate Change related info?

<comment><USER4> Most of the goes-17 bands are in the ir, 14 out of 16, and their nicknames in this table gives some clue as to their use: [https://www.goes-r.gov/education/ABI-bands-quick- info.html](https://www.goes-r.gov/education/ABI-bands-quick-info.html)

<comment><USER8> That's very informative, thanks!

</comment></comment></comment></comment><comment><USER9> Gorgeous.

And, as a curious artist— is the 'GeoColor' image composited by the satellite camera or done manually afterward in post? Mostly, I'd love to see raw stills of the different bands they reference in the image (like the infrared band).

<comment><USER10> Related, you might want to check out DSCOVR- [https://epic.gsfc.nasa.gov/](https://epic.gsfc.nasa.gov/)

If you've never heard of it, this bird always stays on the sunlit side of the planet and takes true color images

<comment><USER4> It takes actual full disk images too! None of this stitching shenanigance without the edge effects that all the geo orbit satelites do.

Goes-17 sees at best 2x2 km boxes (igfov depends on wavelength) and uses mirrors on servos to quickly scan the disk. DSCOVR is simply far enought away that it can see the full disk.

If you need reference materials for how earth like planets look from space, use DSCOVR images, everything else is fake!

</comment></comment></comment><comment><USER11> > GOES-17 is the second in a series of next-generation geostationary weather > satellites. Like GOES-16, its sister satellite operating as GOES East, > GOES-17 is designed to provide advanced imagery and atmospheric measurements > of Earth from 22,300 miles above the equator.</comment>


What is the best open source, desktop application software? - <AUTHOR>

For a project I'm working on, I'd like to build a desktop application that can run on Mac, Linux and Windows without too many modifications.  I would like the application to be built with open source software.  The application I want to build is a simple uploader, with thumbnails representing the files in the list.  What would you consider the best desktop application software for a project such as this?  I'm currently leaning towards WxPython.  Any thoughts? <comment><USER2> Why not build a web app? It will run practically on any platform that has a browser which is basically everywhere. That's basically what I do lately. Anytime I think of neat idea I first prototype it in firefox with the help of firebug and more often than not it turns out to be good enough.

<comment><AUTHOR> I've definitely considered that as a possibility, however part of the application is to discover (search for) files on your system, and then upload specific files based on requests from other people. I was thinking that this would be slightly prohibitive in the web browser, at least from what I know from building Java applets and Flash based uploaders. If I were to do this in the browser, I would want to use purely JavaScript, but I'm unsure if this would be powerful enough for what I want to do.

</comment></comment><comment><USER3> XULRunner with a custom XPCOM component is another option. However for a simple applications WxWidgets is the way to go. Mono is another option.</comment>


Physicists discover "anti-gravity" in bizarre buoyancy experiment - <AUTHOR> https://www.inverse.com/science/physicists-discover-antigravity/ <comment><USER2> It is fascinating how we see black holes behaving like water drops, even the sound NASA transposed from a collision, sending out gravity ripples like ocean waves. Sure it is a visualization technique but still funny that buoyancy is now another helper to explain phenomena.

</comment><comment><USER3> It's more like anti-buoyancy. They put anti-gravity in scare quotes at least.</comment>


Using D and std.ndslice as a Numpy Replacement - <AUTHOR> http://jackstouffer.com/blog/nd_slice.html <comment><USER2> Does D have code for: plotting, optimization, probability distributions, machine learning, Fourier transformations, masked arrays, finanial calculations, structured arrays (read a CSV from disk, get named columns based on the header), SVD, QR and Cholesky decomposition, eigens, least squares, Levenberg Marquardt, matrix inverse and pseudoinverses, integration, Runge Kutta, interpolation, bsplines, fft convolves, multidimensional images, KDTrees, symbolic equation solvers, merge/join of data sets, etc.?

Because I use almost all of these _every single day_ (I don't do multidimensional images or b-splines much at all). Are those all in standard libraries, fully documented, backed by 60 year old, fully debugge code (LAPACK, etc), that I reliably email to anyone across the world and they can immediately run and modify my code because it is such a standard? I honestly don't know, but I'm guessing not.

I use Python/Numpy/Scipy/Pandas/Matplotlib because everyone else in the world knows and uses them; they are a standard. Yes, my np.mean() might be slower than your map(). I almost always don't care. That misses the forest for the trees.

The article might be a good argument for why library writers might consider building out D's standard library to support numerical computation, I dunno. But no one is going to use D for serious number crunching without that infrastructure in place. People moved from Fortran and Matlab to Python not because it is fast, but for the environment. These language tricks are cute and all (I like D well enough, don't get me wrong), but it ain't why we are using Python.

At this point, if I were to switch languages to something without a lot of adoption I'd lean towards Julia. It also have a modern language design, but it is written from the ground up for numerical computation. I can't think of any reason I'd ever reach for D.

<comment><USER3> Yes, Julia is amazing! In the same time, if you want to write a package for Julia you _may_ need to use C/C++. D is going to have integration with Julia in 2016 ;)

D already have good integration with Python. You may want to read this article [http://d.readthedocs.org/en/latest/examples.html#plotting- wi...](http://d.readthedocs.org/en/latest/examples.html#plotting-with- matplotlib-python) (it may be a little bit outdated).

<comment><USER4> What would one need to use c or c++ to write a julia package? It's as fast as native code so no need to use multiple languages.

<comment><USER3> Julia is really fast in 95% cases, but 5% still "make the weather". The pairwise summation is an example. I will post benchmarks D vs Julia next week ;)

<comment><USER5> I would say the biggest benefit of D is static typing. In Julia you can run a simulation and discover only after half an hour that you misspelled a function

</comment></comment></comment></comment></comment><comment><USER6> Credit to the D developers for providing a concise, carefully-designed library for N-D array processing. The chained method invocations demonstrate D's UFCS (Uniform Function Call Syntax) nicely. And it's a definite bonus that you can use underscore like a comma separator in long integer literals (eg, `100_000`).

But if you use Python + Numpy/Scipy/Matplotlib and you're looking for a modern, compiled language for execution speedups or greater flexibility than what Numpy broadcasting operations provide by default, I would recommend Nim. It's as fast as C++ or D, it has Pythonic syntax, and it already includes many of D's best features (including type inference, UFCS, and underscores in integer literals).

And best of all, you _don 't_ need to rewrite all your existing Python+Numpy code into a new language to start using Nim.

The Pymod library we've created allows you to write Nim functions, compile them as standard CPython extension modules, and simply drop them into your existing Python code: [https://github.com/jboy/nim- pymod](https://github.com/jboy/nim-pymod)

The Pymod library even includes a type `ptr PyArrayObject` that provides native Nim access to Numpy ndarrays via the Numpy C-API [ [https://github.com/jboy/nim-pymod#pyarrayobject- type](https://github.com/jboy/nim-pymod#pyarrayobject-type) ]. So you can bounce back and forth between your Python code and your Nim code for the cost of a Python extension module function call. All of Numpy, Scipy & Matplotlib are still available to you in Python, in addition to statically-typed C++-like iterators in Nim+Pymod [ [https://github.com/jboy/nim-pymod#pyarrayiter- types](https://github.com/jboy/nim-pymod#pyarrayiter-types) , [https://github.com/jboy/nim-pymod#pyarrayiter-loop- idioms](https://github.com/jboy/nim-pymod#pyarrayiter-loop-idioms) ]. The Nim for-loops will be compiled to C code that the C compiler can then auto- vectorize.

<comment><USER3> D has integration with Python/Matplotlib too =P [http://pyd.readthedocs.org](http://pyd.readthedocs.org) [http://d.readthedocs.org/en/latest/examples.html#plotting- wi...](http://d.readthedocs.org/en/latest/examples.html#plotting-with- matplotlib-python)

<comment><USER6> It looks like you need to copy your D array to a newly-allocated Numpy ndarray before you can pass it to Python. So there's no binary PyArrayObject interoperability between D & Python (right?). Copying large N-D arrays all the time sounds slow...

(That Matplotlib example uses the function `d_to_python_numpy_ndarray` in the PyD project, which I found defined here: [https://github.com/ariovistus/pyd/blob/master/infrastructure...](https://github.com/ariovistus/pyd/blob/master/infrastructure/pyd/extra.d#L82) . It clearly allocates a new Numpy array: [https://github.com/ariovistus/pyd/blob/master/infrastructure...](https://github.com/ariovistus/pyd/blob/master/infrastructure/pyd/extra.d#L97) )

Also, I couldn't find any examples of invoking D functions from Python. In fact, I could only find mentions on the D mailing list of people reporting that they _couldn 't_ get it to work: [http://firstname.lastname@example.com...](http://email@example.com)

By compiling (transpiling) to C, Nim really does have an unfair advantage in the interoperability challenge...

<comment><USER3> ndslice was merged to DLang master repo today. It is not a problem to fix PyD. (compiling to C is crispy)

EDIT: Exposing-d-functions-to-python [http://pyd.readthedocs.org/en/latest/functions.html#exposing...](http://pyd.readthedocs.org/en/latest/functions.html#exposing- d-functions-to-python)

</comment></comment></comment></comment><comment><USER7> And here we have a case of why microbenchmarks don't work. What you're measuring here isn't a speed difference in the mathematical code, its a constant time overhead from calling into the numerical libs. Up your array size by 100 times and this will become evident.

Why do I say this? Because inlining the python function to

means = numpy.mean(numpy.arange(100000).reshape((100, 1000)), axis=0)

from the original example in the article cut the benchmark time in down from around 215us to 205 us in my testing. That was done by removing a single python bytecode instruction.

Its quite likely that the D numerical code is actually slower than the LAPACK based python numerical code, but you're hiding this in the constant time overhead of a few python function calls.

<comment><AUTHOR> As I stated in the article, I did not include the array creation in the benchmark in order to be fair to Numpy with its slow initialization times. The only python code that I benchmarked was the numpy.mean line.

<comment><USER7> That still doesn't matter. So much of the work is being done in python that you're benchmarking the overhead of python, not the numpy speed.

I mean this is a terrible benchmark. Comparing to pure python, the numpy code is about 4-5x faster on my machine, whereas in reasonable real world benchmarks, numpy is hundreds of times faster than pure python.

For reference my benchmark was

        %timeit [sum(row)/len(row) for row in mat]

and it completed in about 900us, given mat was a python 2d array.

These results are as valuable as the ones pypy gave me:

        pypy -mtimeit -s "[sum(row)/len(row) for row in [[range(100000)[i*j] for i in range(100)] for j in range(1000)]]"
        1000000000 loops, best of 3: 0.00101 usec per loop

Edit:

In other words, because the code returns a python array of length 1000, what you're benchmarking is python's speed of array instantiation vs. Ds mathematical speed. Its obvious that D will win. The only fair way to benchmark the mathematics here is if you compare the D implementation of O(n) algorithm that returns a single value, or an O(n^2) algorithm that returns a 1d array or single value etc. Otherwise the python overhead of creating O(n) objects will overshadow the actual mathematical calculations on those O(n) objects.

<comment><AUTHOR>
        you're benchmarking is python's speed of array instantiation vs. Ds mathematical speed. Its obvious that D will win.

Not true, the D code also has the overhead of array initialization. std.array.array is called which allocates the results of the range into an array on the GC, which everyone bemoans as being slow as a dog.

Plus, I don't see why this is an invalid benchmark when this is perfectly normal Numpy code, the kind that you see all the time. That was the reason behind the benchmark, to find some common piece of Numpy code and see how equivalent std.ndslice stacked up. I don't see how it's fair to say "Python is really slow at this one thing, so it's not fair to compare it to D in that area".

<comment> semi-extrinsic He's absolutely right, this is a crappy benchmark. Increase the array sizes by at least a factor of 100 to get anything meaningful.

The fact that someone who is "the review manager for std.ndslice's inclusion into the standard library" does not understand how to profile numerical algorithms makes me very skeptical of using D for any numerical project.

Plus, the syntax looks god-awfully unintuitive. A main advantage of Python is that you often get "code that looks like what it does". The D "basic example with a benchmark" OTOH looks almost obfuscated. To wit; a Fortran version is more readable, is fewer lines of code(!) and of course kicks D's butt when it comes to speed:

      program p
      real, dimension(100,1000) :: data
      real, dimension(1000) :: means

      n=1
      forall(i=1:100,j=1:1000)
        data(i,j)=n
        n=n+1
      end forall

      forall(i=1:1000000,j=1:1000)
        means(j) = sum(data(:,j))/size(data(:,j))
      end forall

Disclaimer: I wrote this on my phone, only 95% sure that it will compile and run correctly. Save it in means.f90 and compile with `gfortran -Ofast means.f90`. This calculates the means 1 mill. times (the loop over i in the second forall); I bet you it will be an order of magnitude faster than D per means calculation if you time it with plain time (the *nix command).

<comment><AUTHOR> "Increase the array sizes by at least a factor of 100 to get anything meaningful."

Ok, let's do that and see what happens:

        python -m timeit -s 'import numpy; data = numpy.arange(10000000).reshape((1000, 10000))' 'means = numpy.mean(data, axis=0)'

D code

        import std.range : iota;
        import std.array : array;
        import std.algorithm;
        import std.experimental.ndslice;
        import std.datetime;
        import std.conv : to;
        import std.stdio;

        enum testCount = 10_000;

        void f0() {
            auto means = 10_000_000.iota
                .sliced(1000, 10000)
                .transposed
                .map!(r => sum(r) / r.length)
                .array;
        }

        void main() {
           auto r = benchmark!(f0)(testCount);
            auto f0Result = to!Duration(r[0] / testCount);
            f0Result.writeln;
        }

Results

        Python: 14.1 msec
        D:      39   μs
        D is 361.5x faster

<comment> semi-extrinsic Ok. So three points remain:

* how do I know that the calculations aren't actually optimized away in all that code I can't understand? E.g. what happens if you make f0() return the means array instead of being a void function?

* Given the same number of lines (or characters), are you sure you can't write equally fast Python code?

* I tested the Fortran version on a slightly slower computer (got 14.7 msec on the Python version). Fortran runs at 0.7 μs, i.e. > 55x faster than D, with less code that's more readable to boot.

<comment><AUTHOR> "how do I know that the calculations aren't actually optimized away in all that code I can't understand? E.g. what happens if you make f0() return the means array instead of being a void function?"

If you can't understand the code, how did you know it was a void function. Please stop with the hyperbole, it's not adding anything to the discussion.

Updated code:

        import std.range : iota;
        import std.array : array;
        import std.algorithm;
        import std.experimental.ndslice;
        import std.datetime;
        import std.conv : to;
        import std.stdio;

        enum testCount = 10_000;

        auto f0() {
            auto means = 10_000_000.iota
                .sliced(1000, 10000)
                .transposed
                .map!(r => sum(r) / r.length)
                .array;
            return means;
        }

        void main() {
            auto r = benchmark!(f0)(testCount);
            auto f0Result = to!Duration(r[0] / testCount);
            f0Result.writeln;
        }

Results:

        Python: 14.1 msec
        D:      41   μs
        D is 343.9x faster

"Given the same number of lines (or characters), are you sure you can't write equally fast Python code?"

IMO program size is an almost meaningless statistic outside of code golf challenges. LOC is not an indicative measure of code readability, usefulness, or organization.

For example, your Fortran code was 11 lines while the D function (with the return) is eight lines.

"I tested the Fortran version on a slightly slower computer (got 14.7 msec on the Python version). Fortran runs at 0.7 μs, i.e. > 55x faster than D, with less code that's more readable to boot."

Just goes to show why Fortran is still used in a lot of scientific areas.

But two things:

1\. Fortran is a much simpler language than D or Python and is much harder to do multipurpose work in it (so I'm told from Fortran programmers, I don't know Fortran myself). So when your program needs to do anything other than number crunching, it's normally done in a separate language. Using D you can have everything in one code base.

2\. This article was about Numpy and std.ndslice because those are two areas that I know about and Numpy is a very popular library. Bringing up Fortran's speed here is like commenting on how much faster C++ is in a thread about Ruby.

Also, readability is a subjective idea; I believe the D code is more readable than the Fortran you wrote. Different strokes.

<comment> semi-extrinsic > If you can't understand the code, how did you know it was a void function. > Please stop with the hyperbole, it's not adding anything to the discussion.

I understand "void" perfectly fine, but understanding how D optimizes your code is a completely different matter. Playing devil's advocate further, you

> IMO program size is an almost meaningless statistic outside of code golf > challenges. LOC is not an indicative measure of code readability, > usefulness, or organization.

No, but the numpy code is undoubtedly much simpler, and very general. How does the D example look for a 3D array where you want to average over the second dimension?

> For example, your Fortran code was 11 lines while the D function (with the > return) is eight lines.

You're neglecting the library imports.

>So when your program needs to do anything other than number crunching, it's normally done in a separate language. Using D you can have everything in one code base.

I do agree other languages are much better for e.g. string processing. But for the applications where you can afford to trade simpler code for 50x slower performance, I'd say you're not really caring about performance at all, so why not just use Python? If performance is mission critical, a two-language code base (Python + C/C++/Fortran/CUDA) is not that hard to do, fairly common, and will give you the required performance.

> Bringing up Fortran's speed here is like commenting on how much faster C++ > is in a thread about Ruby.

No; once you start saying "I want more performance than Python", it's obviously interesting to see what level of performance a "low-level" language gets, to put the result in perspective.

Now, I'm not trying to beat down on D, so please try to interpret this as constructive criticism. Finding "where does it fit in the scientific toolbox" is what makes or breaks a language's adoption in the scientific community. Just look at R, it's at the same level of performance/abstraction but in a separate niche from Python, and doing very well. The same goes for Matlab (which has e.g. Simulink).

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I occasionally rewrite Python+NumPy signal processing code in C++ for purposes of packaging and integration with native apps, so I read these examples with an eye to how they compare with typical C++, rather than with NumPy. They compare very well, and it would never have occurred to me to look into D as a possibility for this sort of code.

I'm guessing the GC might rule it out for many cases where you do signal processing in C++, but I may as well ask: what's the deployment side of things like? Can I easily build a shared library and use it from a C++ application?

<comment><USER6> You might also be interested to check out Nim. It transpiles to C before invoking the C compiler, so it runs as fast as C++ and has excellent C-compatibility (and by extension, excellent C++-compatibility).

Compiling a shared library is as easy as passing the "\--app:lib" option to the Nim compiler: [http://nim-lang.org/docs/nimc.html#compiler-usage-command- li...](http://nim-lang.org/docs/nimc.html#compiler-usage-command-line- switches)

The GC is optional; you can manage your memory manually if you prefer: [http://nim-lang.org/docs/manual.html#types-reference-and-poi...](http://nim- lang.org/docs/manual.html#types-reference-and-pointer-types)

The Nim tutorial is here if you want to have a quick skim: [http://nim- lang.org/docs/tut1.html](http://nim-lang.org/docs/tut1.html)

<comment><USER9> Please stop this. It's approaching spam. Someone put a lot of work into building a new capability into a language and writing up a lengthy blog post about it. If you want to do the same for what you think is good about Nim and submit it to HN, please do. Repeatedly intercepting people's question about D with "you should look at Nim" is obnoxious. If D users did this in a thread about Nim, I imagine you would find it frustrating.

</comment></comment></comment><comment><USER10> Am I correct in thinking that this is only reasonable if you're already using D? The switching cost seems too high if you're python everything.

I tried the Armadillo C++ library a while ago ([http://arma.sourceforge.net/](http://arma.sourceforge.net/)). The speed up and time spend learning the syntax didn't seem worth it.

<comment><AUTHOR> I completely understand that for existing projects it might not make sense to switch, but as I say at the start of the article

        why you should consider D for your next numerical project.

<comment><USER10> I just ran your column means benchmark. It is pretty impressive... maybe my C++ is trash. Never saw that much speedup with Arma. I'll try it out :)

</comment></comment></comment><comment><USER11> The central claim of the post seems summarized by this quote:

> For example, when using a non-numpy API or functions that don't use Numpy > that return regular arrays, you either have to use the normal Python > functions (slow), or use np.asarray which copies the data into a new > variable (also slow).

but I disagree strongly with this.

First of all, if there is a common use case for some set of operations that need to be performed on very large data (the type of data you'd look to NumPy to handle), then generally there is already a subpackage within numpy/scipy/scikits/pandas/etc that already deals with that use case and natively handles it with NumPy arrays, with no switching cost to convert back forth between lists or tuples or whatever.

And, of course, when a list/tuple-heavy API is only meant to deal with small data, it's not a problem to use NumPy's facilities for converting between ndarray and the builtin array types. In cases where you're dealing with a huge breadth of small data, then that casts doubt on whether you should be using NumPy; it wouldn't be casting doubt on whatever the other list/tuple-heavy API is. And probably parallelization (or even the buffer stuff I mention below) is a fine solution in that case.

Second, in a lot of cases you can make use of the Python Buffer Protocol to share the underlying data of a NumPy array without copying it. This won't help if some other API expects Python lists or tuples, but the great thing about dynamic typing in Python is that all that really matters is that whatever underlying buffer type you need implements whatever methods that other API expects to call.

You can always write your own extension type that adheres to the Buffer Protocol and also provides whatever API is needed to conform to some other library, so the power to create these double-sided adapters (one side sharing data with NumPy, the other side appearing like a drop-in acceptable data structure for the other library API) is very powerful and generic. It might take some getting used to the first few times you do this, but if you use tools like Cython to help, it's really quite easy to do, easy to maintain, and solves a surprisingly wide range of NumPy integration problems. In fact, these things generally already exist for most problems you will run into and ultimately they often boil down to simple Cython-based wrappers around C bindings to the other Python API you're working with.

I would argue that the existence of this Buffer Protocol adapter strategy alone is enough to say that the switching cost to D is virtually never worth it, and still pretty speculative even if you're starting a brand new numerical computing project.

Finally, most Python libraries that heavily rely on the list or tuple APIs are not meant for large data (those APIs mostly already just use NumPy, as I mentioned, or else they use generators and let the end user decide which array type will eventually be instantiated as the results are consumed). It's not common, by intentional design, for list/tuple-heavy APIs to need to cope with large data, so when someone says something off the cuff like "What do you do when some library API needs lists and you've got NumPy arrays?" it _sounds_ like a worrisome case, but in practice it's really, really uncommon that such a situation arises and no one else ran into it before you and no one has created a NumPy-compliant solution already. It's not impossible, of course. Just unlikely, and probably not important enough to use as a basis for language choice, unless you're facing a really special sort of API problem.

Edit: None of this should read at all as a criticism of the D language or this particular implementation of ndarray data structures. All that stuff is great and anyone wishing to use D absolutely should.

I'm _only_ arguing against the post's central thesis insofar as it is used to justify considering D as an alternative to scientific Python. The problem that the post points out already has solutions solely in the Python ecosystem, many projects have handled that problem before, and the problem is pretty rare and esoteric anyway, so it's probably not a good thing to use as the basis of an important choice like which language to use, or whether to switch languages.

There could be many reasons to prefer D over scientific Python depending on a given use case, and there could be certain situations where switching from Python to D is a good idea. Whatever those cases may be, the central issue of this post, performance degradation caused by NumPy-to-other-API compatibility, is _not_ one of them.

<comment><USER12> Very nicely put and I agree. What I was expecting to see in the list of numpy problems mentioned in the article wasn't there. The major problem that makes Numpy performance lag behind C++ or Fortran is the extra level of indirection that is needed for accessing an element (via stride ptr), and the need for extra copies that is forced on you by vectorization. Numexpr can help for certain cases of the latter, but its still quite limited in the type of expressions that numexpr can handle. It is my belief that with some local static analysis both can be mitigated somewhat.

It would be really interesting to see whether D's nd object tackles these issues. The copy of arrays across function boundaries, as you correctly pointed out, is mostly a red herring.

<comment><USER4> Numba obviate these issues

<comment><USER12> I see your excitement about Numba, I guess you follow it closely, or perhaps have other valid reasons. So all the best. However, the last time I tried to use it, about 4 months ago, installation was a bitch and it would crap out compiling some functions. It holds promise of course, so does alternatives.

What I think the current post is about is that similar nice and performant abstractions for D. I love Python a lot but I have to pay extra attention so that it is performant, so that I don't make stupid typos. I have to rewrite parts in Cython or Weave (sadly the latter gets no love anymore). Larger the code base becomes I have to spent more time in the tail part of the 'tooth to tail' ratio. In D many of these are taken care by default, I have to worry a lot less about these things. The other fantastic thing is DMD has super fast compilation times. It used to be faster than Go in compilation time but the latter has caught up in that department (grossly lacking in others). D binaries execute a lot faster (when compiled with LDC or GDC). It may lack some libraries here and there, but that does not worry me as much, everyone has to start somewhere, and to be honest Python is lacking in that respect compared to R. What would be worrisome is the presence of structural aspects that may get in the way of such an eco-system emerging. I don't see anything of that kind in D.

In anycase I don't quite see how Numba obviates the issues I mentioned. It does not change the Ndarray representation, and the extra indirections lay right there. OTOH some copy elision I would grant.

I can give concrete examples. The isotonic regression implementation in scikits.learn was absolutely pathetic. It has been rewritten several times and its performance is still severely lacking in spite of being Cythonized. You can take a stab at it with Numba and see what you can do. In C++ (D would have been nicer) the very first idiomatic implementation in STL was faster than any of these rewrites. I wrote it once and moved on. But C++ is a horrifying mess, now if there was a language that gave me C++ performance (not asking for much) but none of the mess and numpy level expressiveness to boot, that would be sweet. Julia, Nim, D, PyPy are some of the contenders trying to reach this holy grail

<comment><USER11> Numba certainly does not obviate all of these issues. I think user `tadlan` is referring to some of the compiler optimizations, like loop unrolling or fusion (e.g. noticing that two subsequent loops can be 'fused' into the subordinate execution block of one single loop). These things can offer speed-ups even beyond NumPy, and they can work even when the Python code you start out with already uses NumPy.

The thing is, which `tadlan` seems unaware of, a lot of this stuff just fails in production environments and hits corner cases that the Numba compiler does not handle (I'm talking about the first part of the Numba compiler pipeline, where it converts to _Numba_ IR, and not yet to LLVM IR, and does things like examine the CPython bytecode to alter the representation from a CPython stack- based representation to a register-based representation that will be compatible with LLVM and ultimately with the actual machine itself). In _that_ compilation step, the only things that are able to be handled are things that the Numba team (I used to be a member of it) explicitly support. They don't support a full-blown compiler for the entire Python language, nor even for every type of NumPy operation. That's not a knock against Numba at all -- it's a _specializing_ compiler and obviously they need to prioritize what to support, and make longer term goals about supporting more general things. But the point still remains that you cannot just assume that if you call `jit` on any arbitrary Python code, it will always become faster. In some cases, it can even become slower.

I suspect `tadlan` is very interested in Numba and enthusiastic about knowing the taxonomy of Numba details, but it does not seem like that user has had real world experience trying to get Numba to work in production, and seeing all of the numerous buggy and missing features. I don't want to diminish anyone's enthusiasm for Numba, so it's probably best just not to engage with `tadlan` about it. That user's mind seems made up already.

<comment><USER13> As a former member of the Numba team, what is your outlook on the technology and the broader continuum ecosystem?

I'm looking at Numba and friends (Dynd, blaze) for a new stack, but I'm not sure where the development arc will end up vs say Julia. I'm also curious about the sustainability of Continuum's business model and practices in the medium and long term.

Any thoughts on this? I understand if you are limited in what you can say, but I'm open to any nuggets.

<comment><USER11> This is one of those questions that is extremely hard to predict. Even though I was part of that team, it doesn't mean I have any special insight into what will happen.

A lot will depend on sources of funding. Will folks like Nvidia start sponsoring Numba, and if so what will it mean for support of Nvidia alternatives like OpenCL?

It seems like NumbaPro as a stand-alone for-pay product is not viable on its own, but that claim could be wrong based on more recent data that I don't have access to. So external sponsorship may be necessary.

One form of this could be through Continuum's already established business model of consulting and support services. But then the question is whether the nature of those consulting and support projects will allow for developers to actually further the cause of Numba, or just merely hack in poorly conceived features that are demanded by the consulting and support customers? Since Numba is open source, it should be easy enough for anyone to follow along with commits and discussions on GitHub and make their own opinion about what direction that is going.

The other question that is always hard is staffing. Far and away the colleagues I had the chance to work with on the Numba team were amazingly good. But it's not clear if working solely on Numba can justify the sort of salary that would be required to attract very top engineers and grow the team. You might start to see more interns and/or post-doc type labor feeding into Numba, and again I don't know what that will mean for the project ... could be good or bad.

At the same time, you've also got a lot of active development for Julia, PyPy, and a lot of people still prefer to use Cython rather than jitting functions. Some people even call into question the entire goal of making something that is "easy" but also a "black box" \-- like the way just dropping in `jit` works for people who merely use, but don't understand the inner workings of, CPython.

It's an exciting area, and the Numba team has as much talent and ability to claim a significant piece of the tool space surrounding high performance computing as anyone else. Whether that will pan out for them is still really hard to predict.

<comment><USER13> Thanks very much for your thoughts.

What do you think about the foundational tech of numba itself?

Do you think it is any more of a black box than say Julia? Is there anything about it that would impede extension into a more stable, predictable and feature rich product?

BTW looks like Intel is doing some stuff with Julia: [https://github.com/IntelLabs/ParallelAccelerator.jl](https://github.com/IntelLabs/ParallelAccelerator.jl)

There has also been alot of recent funding to Continuum and dev of numba seems to be going strong. Also some recent work with AMD.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> Use numba to compile python loops or array expressions to fast llvm, and problem solved. I'm sticking with python.

<comment><AUTHOR> Considering that in the benchmarked example, only one like of Numpy code was used which already uses compiled C, I have a hard time believing that that would catch up to using all compiled code.

<comment><USER4> Numbs compiles entire functions on and allows array expressions with allocation and loop fusion. I don't see the problem

<comment><AUTHOR> The benchmarked code is ALREADY a comiled C function called from Python and it still lost.

<comment><USER4> Numba would still be faster. It would fuse away any intermediates in the code and remove any Overhead to the compiled code.

also have the option of devecting to loops.

both of which are generally faster than vectorized jumpy code.

<comment><USER11> While I agree broadly that the benchmark example in the post is not representative or useful as a comparison between D and NumPy, I disagree with your strong insistence on Numba in this case.

There is still _a lot_ of Python code that the Numba-to-LLVM compiler cannot handle. Yes, it is true that Numba can do a decent job of removing CPython virtual machine overhead, even for functions in which you statically type the arguments merely as 'pyobject' \-- but not universally.

And there are also a ton of super basic things, for example creating a new array inside the body of a function when using Numba in 'nopython' mode [1], that Numba doesn't handle. These things will improve over time, but they may not improve quickly enough for a given use case, and the D language and this ndarray implementation may be a fair competitor to Numba in the short-to- medium term (and could even be superior in the long run, who knows).

A fairer alternative would be comparing with the use of Cython, which for my money still hands down beats anything like D or Nim/Pymod for performance enhancement without sacrificing pleasantness of design and development.

Though, of course, none of this stuff holds a candle to Haskell :)

[1] < [http://stackoverflow.com/questions/30427081/creating- numpy-a...](http://stackoverflow.com/questions/30427081/creating-numpy-arrays- inside-a-function-decorated-with-numbas-jitnopytho) >

<comment><USER4> Actually, Numba array allocation in nopython mode is allowed now.

What other numerical features are missing?

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> click-bait. Why should I change my language even if I'm looking for a numpy replacement?

<comment><AUTHOR> How is this clickbait? Did I in any way misrepresent the content of the article?

If you don't like D and don't want to use it move on to the next item on the front page.</comment></comment>


How did you like the new episode of Silicon Valley? - <AUTHOR> As I was watching the new episode of Silicon Valley (Season 4 Episode 1) I noticed that they took a very big turn in the show and some would say "ruined" it. What do you guys think?<p>Notice: I have noticed that most people who have watched it either thing it was really good or really bad... <comment><USER2> As long as Gilfoyle and Dinesh still have their love/hate-relationship going, that's enough for me. I think the turn was decent. The show could use a new idea since the old "pied piper"-project has been up and down in every possible way the past 3 seasons. A new character would help liven up the show though.

</comment><comment><USER3> The show needed to pivot. I think they painted themselves into a corner with the plot. If someone did create a new better compression technology, they would just patent it and live off the royalties. Or just sell a binary library to every software vendor on the planet.

Personally I preferred the show Beta's for it's prospect of a social network trying to get established. There would be a lot of mileage in that.

Having said which Silicon Valley Season 1 Episode 8 was pure genius in terms of comic hilarity.

</comment><comment><USER4> Brilliant. I loved the turn, and I can't wait to see them flesh out the whole "new internet" plot. Only part I didn't like is that Bighead is back.

Yeah, the dynamic will change, but it would have stagnated otherwise.

<comment><USER5> I bet something related to blockchain technology :)

</comment></comment><comment><USER6> I tried to watch it but the Netflix queue has it backlogged.

I bought a copy of season 3 from Amazon. But HBO has locked it up with DRM and it won't play on any device I have. DO NOT BUY IT THIS WAY.

I love the show and can't wait to see it.

<comment><USER7> _I bought a copy of season 3 from Amazon. But HBO has locked it up with DRM and it won 't play on any device I have. DO NOT BUY IT THIS WAY._

One of the top reasons torrenting copied material remains popular. the majority of stuff I buy, I also download via torrent.

</comment></comment><comment><USER8> The premise is still there, however, EP1 of S4 seemed a bit acted/stiff... WTF is Erlich doing smoking a cigarette? What happened to the big ass bong?

</comment><comment><USER9> I felt the dialog was not on par. Something was a bit off. Can't put my finger on it. Still waiting in excitement for the next episode though :-)

</comment><comment><USER10> I don't like how Richard and Dinesh are giant assholes this episode. We'll see where it goes though.</comment>


Rant: The DRY Principle Is Bad Advice - <AUTHOR> https://medium.com/@rotemtam/the-dry-principle-is-bad-advice-78c51afd5cf0 <comment><USER2> DRY is simple and should not be thought too much off.

Don't Repeat Yourself. Too many developers look at this principle with refatoring in mind, a lot more than it should be.

If you have duplicate code, and by duplicate, i mean exact copy, then this principle applies. A 90% duplication is not a copy. It's close, but it's not a copy.

Abstractions often come with a much higher cost than duplication. It's much easier to get your abstractions wrong than it is to keep things stupid and repetitive.

Time is your friend here. Don't ever start abstracing, introduce it slowly and a small bit at a time.

</comment><comment><USER3> I stopped reading at the point where the article gave an example of the clients of the shared code being given extra responsibilities and claimed that the fact that both clients called the same library function meant that they could not be separately changed to cope with the new responsibilities.

> you can't change one without the other.

That's just nonsense. All the coder has to do is either make the shared code parametric or take a copy of it and hack it until it works (choose the approach that makes the most sense at the time). Alright, now it isn't shared, but so what? You can't always predict with certainty that the clients won't share the code at some distant point in the future any more than you can predict before writing it which bits of code will definitely be candidates for sharing.

</comment><comment><USER4> The hardest thing about growing up in this field is understanding that every day is a practice of a dealing with competing priorities.

As an example, I'm currently writing my own programming language at the moment for board games. I'm prioritizing shipping a game for my friends and myself to play, and this is forcing to leverage WET a great deal because I do not have the primitives yet to even contend with DRY.

Now, interestingly enough, this has been fortuitous since I have many touch- points which enable specific tweaks influence by game rules. Without WET, I could see myself not making progress or refactoring endlessly.

This is leading me down an interesting path, and I'm finally old enough to appreciate that things are going to be messy and weird.

</comment><comment><USER5> This seems like terrible advice and a terrible clickbait title.

His conclusion is even this:

> Coming full circle, I must admit, the DRY principle is a pretty important > piece of advice after all

So DRY is fine. Just be sure you're deduplicating for the right reasons. Like every other "rule" we have out there for programming, there are caveats and you shouldn't be blindly applying rules.

I hate people like this.

<comment><AUTHOR> If it got you reading all the way to the end and considering where and when should DRY be applied, what are its origins, and what are its limitations then I guess the title did its job just fine.

<comment><USER6> No, regardless of the outcomes it's not okay to trick people into reading your article through misrepresenting yourself.

<comment><AUTHOR> here, a question mark was added to the title to better reflect the contents of the article. [https://medium.com/@rotemtam/the-dry-principle-is-bad- advice...](https://medium.com/@rotemtam/the-dry-principle-is-bad- advice-78c51afd5cf0?source=friends_link&sk=8f5d77ebee500b15d4427f419f792572)

</comment></comment></comment></comment><comment><USER7> DRY is just a principle. It must be applied in accordance with common sense. As a character of one of Asimov's book used to say, "Never let your sense of morals get in the way of doing what's right".

</comment><comment><USER8> "Repeat yourself for max 3-5 times" is a much better principle.

Copy & paste is a fundamental principle for reason. Just when it becomes a burden you need to abstract.</comment>


Hunch engineering is answering questions on formspring - <AUTHOR> http://www.formspring.me/huncheng

<comment><USER2> Question: How do you control false positive rate mining correlations?

Answer: We use false positives as a negative feedback mechanism which refines our models. We have dials for precision and recall depending on how much we want to risk looking stupid.

I would be highly interested in seeing how _strongly_ this feeds into their system. A bit too much of the false positivity taken into account could make them look way too cautious and hinder any sort of adventurous recommendations. I'm sure they have taken this into account, though.

</comment><comment><USER3> Interesting response to "What do you think about TDD?" "I'm assuming you mean test driven development...taken to an extreme I think it doesn't make much sense for a consumer web startup. Probably makes more sense if I was building the space shuttle."

Space shuttles are traditionally built with formal methods and SEI CMM Level 5, so it's pretty hard to see them going the agile route. Conversely if done well, TDD's great for a web startup because it makes it so easy to evolve.

</comment><comment><USER4> Some of their answers seem a little nonsensical. Python, for example, is not blazingly fast, but it is good for some things like I/O bound systems.

</comment><comment><USER5> The linked page breaks the back button. Why would they do that?</comment>


Yogscast Kickstarter failure is a painful reminder of the risks of crowdfunding - <AUTHOR> http://www.polygon.com/2014/7/17/5912245/yogscast-kickstarter-failure-crowdfunding-risks <comment><USER3> So 13.000 people risked $50, and they lost. This is a painful reminder? It's just $50, it's no ones livelihood except the that of the Winterkewl people. They thought they could do something, turns out they couldn't.

Why does this author take offense to the tone? Isn't it clear as day? The game won't be made, so the backers won't get their reward. The studio did their best, but it wasn't enough so now they're stopping. Yes the Kickstarter says there should be a refund, but obviously the studio should have spend all of their money by now. That refund clause is just to make sure companies don't go taking money without being indebted to the backers if they fail. This one does go bankrupt, so everything is in good order.

He says Yogscast and Winterkewl are to blame, what for? For attempting to do something cool for their fans but failing? There's no shame in that.

<comment><USER4> So you're saying that if I overpromise something and get a bunch of people to give me money for it, I have an escape hatch to never repay the money? Then it's appealing to start some BS kickstarters, never deliver, and never refund the backers (and isn't that a problem already?).

Is Yogscast to blame? Sure - they misled people into paying for overhyped vaporware by throwing their name on it. They also have the money to refund people, and right now they're trying to hang on to their money as tightly as they can.

<comment><USER5> The escape hatch is either you going bankrupt and/or refunding people, sure. Not much of an escape hatch, really. Also, if you endorse and support something like this and it fails your reputation takes a hit.

I don't think it's a big deal when it comes to luxuries like that. Also, I like kickstarter for supporting people who do cool stuff they can't finance any other way. I really don't care if they fail or not too much since I don't spend much money on it. (Hey, and for me personally it has always worked out so far.)

<comment><USER6> Maybe we need a Kickstarter competitor that is a lot more clear in its marketing that backing a project is a donation to people making something you think is cool, with those people sending you something as thanks if they are able to. I get so frustrated with the perception of Kickstarter as a pre-pay store and Kickstarter's inability or unwillingness to change that perception.

</comment></comment></comment></comment><comment><USER7> Caveat emptor.

A rule of thumb I learned from my parents long ago is when you see something you want to have, wait two weeks. If you still want it in two weeks, and can afford it, then buy it. I suspect a little bit of waiting and research would have informed these backers to the potential disaster that was coming. I remember this kickstarter and I thought it was a joke, but the fans don't want to hear that.

<comment><USER8> I think the problem with game related kickstarters is that a lot of the backers are probably fairly young and have a poor understanding of the amount of resources and risk involved in a project of this size. To an 18 year old $0.5 mil sounds like a lot of money and it would seem like it should be possible to make 3 games with that much but they don't understand how quickly it can get swallowed up because they have limited experience with the business world.

<comment><USER9> So they spent $50 dollars to learn a life lesson. Honestly, that much cheaper than it could be. If the game designers were deliberately trying to exploit this then there would be a problem.

</comment></comment></comment><comment><USER10> Lewis from Yogscast had some responses on Reddit a couple days ago:

[http://www.reddit.com/r/Games/comments/2apng1/yogscast_cheat...](http://www.reddit.com/r/Games/comments/2apng1/yogscast_cheat_backers_for_567000_on/cixkr3u?context=1)

</comment><comment><USER4> I think this is ripe for a lawsuit if money is not refunded. You can name both Yogscast and Winterkewl in the suit knowing that Yogscast has enough money to pay damages. Yogscast would then try to get out of the suit, but it'd be tricky for them to shed their responsibility in the matter (which apparently they're trying very hard to do, according to the article).

<comment><USER11> Kickstarter's terms are very clear that you may receive nothing in return for your money, just like with other investments.

<comment><USER12> A) It's not an investment.

And B) their terms don't say anything like what you said:

Is a creator legally obligated to fulfill the promises of their project?

Yes. Kickstarter's Terms of Use require creators to fulfill all rewards of their project or refund any backer whose reward they do not or cannot fulfill. (This is what creators see before they launch.) This information can serve as a basis for legal recourse if a creator doesn't fulfill their promises. We hope that backers will consider using this provision only in cases where they feel that a creator has not made a good faith effort to complete the project and fulfill.

[https://www.kickstarter.com/help/faq/kickstarter+basics](https://www.kickstarter.com/help/faq/kickstarter+basics)

<comment><USER13> If the company has burned through all their money though, it's kinda hard to draw blood from a stone...

<comment><USER14> Since they've setup an LLC apparently, the end developers won't be held personally liable (and I don't think they shouldn't be), so if it comes to a lawsuit and there isn't any cash left to refund, that will be the end of it.

</comment></comment></comment></comment></comment><comment><USER15> Eh, that's how it goes. Sometimes development pans out; sometimes, it falls flat. With crowdfunding, we the people get to choose what things we want instead of publishers - which does mean we take the risks in case it misses the mark, and that is a very _real_ risk.

I backed this one myself; a little bit, basically to see what happened. I like YOGS (back to when I played right alongside them on WoW, actually - <USER2> world!). They're always looking for another fun platform to play/tell stories with. The developer/s were inexperienced; although it wasn't quite clear just _how_ green they were, I was aware that this one was looking a bit wobbly, as I'd never heard of them, and I _was_ getting Molyneux vibes from the promises.

After I saw the alpha and beta, it was clear Winterkewl just couldn't deliver the goods to anything resembling a reasonable quality, which is why Yogscast didn't feel comfortable really going forward with it like that any more.

Pity about the lead dev's marriage. Isn't the first marriage killed by game development; won't be the last. Obviously the studio is bankrupt (or to the extent that it isn't, needs to refund).

Interesting to see Yogscast did at least get the source and assets out of the ruins of this project (although they're not very _good_ assets, unless you really want a dwarf beard simulator), and they seem to have some kind of rescue plan with another studio. Let's see what happens.

I'm pretty sure no-one's swimming in half a million quids' worth of Jaffa cakes out of this one - but that's development. Sometimes it goes like this and goes nowhere. Sometimes (like Elite: Dangerous, which is turning out _brilliant_ ) it goes to the stars.

I'm actually glad _we_ can choose to take these risks with crowdfunding. Just, you know, remember it's not a pre-order.

</comment><comment><USER16> One of the more interesting things is that the demos were almost entirely just the demo form a marching cubes package they bought on the Unity Asset store for $100 [1]. Even down to the textures. The only additional feature were the two rigged characters and a those few building meshes.

The creator of that package, formerly an enthusiastic developer of a cool product, pulled his product from the asset store when yogcast's kickstarter hit half a million and apparently abandoned game development entirely.

[1] [http://forum.unity3d.com/threads/introducing-voxelform- voxel...](http://forum.unity3d.com/threads/introducing-voxelform-voxel- terrain-marching-cubes-with-real-time-deformation.94224/)

<comment><USER17> I skimmed through that thread. For those interested, here are the salient posts.

Where winterkewl finds the package: [http://forum.unity3d.com/threads/introducing-voxelform- voxel...](http://forum.unity3d.com/threads/introducing-voxelform-voxel- terrain-marching-cubes-with-real-time-deformation.94224/page-6#post-823980)

Where the creator acknowledges that winterkewl is using the package for the kickstarter campaign: [http://forum.unity3d.com/threads/introducing-voxelform- voxel...](http://forum.unity3d.com/threads/introducing-voxelform-voxel- terrain-marching-cubes-with-real-time-deformation.94224/page-7#post-893009)

Here is where the creator pulls the package: [http://forum.unity3d.com/threads/introducing-voxelform- voxel...](http://forum.unity3d.com/threads/introducing-voxelform-voxel- terrain-marching-cubes-with-real-time-deformation.94224/page-7#post-928356)

</comment></comment><comment><USER18> They should release the unfinished game and source code/assets to backers as a sort of liquidation.

<comment><USER19> I'm a little surprised this hasn't become an accepted practice yet... Tons of game developers fail to complete their projects for one reason or another, and the open-source scene for PC games is practically non-existent (actual games, not middle-ware). I wouldn't expect publishers to ever open-source unfinished games, but for indies that don't need to protect their IP, it seems like it would be a pretty great move to open-source your code and assets under a non- commercial license, if you can't complete a relatively mature project.

It seems to me that it would be beneficial to everyone involved... but maybe I am missing something.

<comment><USER20> It's because so often they leave it reluctantly, hoping to finish it sometime in the future. I also think there's the gaming community in general has a culture that puts ideas on a pedestal as this great commodity that's inherently valuable.

</comment></comment></comment><comment><USER21> The failure of these Kickstarter projects is several orders of magnitude less than what we will see when crowdfunding of startups hits full stride. It's a snakeoil salesman's wet dream, to be able to sell a great idea, "fail" and say "sorry, we tried". The only difference is that it will be 13,000 people losing $50 as opposed to a handful of rich people losing $1M each.

</comment><comment><USER22> Kickstarter is an interest free business loan with absolutely no obligation to deliver or recourse if they do not. You'd have to be a damned fool to Kickstart anything for-profit, and people Kickstarting things think you're an idiot ripe for exploitation. If you want money to start a project take out a loan or sell equity.

</comment><comment><USER23> I don't really have a problem with this. Kickstarter projects shouldn't lead to backer entitlement. Campaigns are a risk that everyone can pitch in a little for in the hopes of success. Pledge at an amount appropriate to risk and you'll lose the bet here and there, but it's part of the game.

<comment><USER13> Kickstarter need to create rules that protect the backers who can't reasonably be expected to understand the risks. 1% of the project's funds could've paid for an industry expert to take a look at their project plan and tell you they are likely going to fail.

</comment></comment><comment><USER24> "The Yogscast's Yogventures was the first Kickstarter I ever saw that set off alarm bells in my head" What? Was this also the first Kickstarter the article author ever saw?</comment>