Node.js is Cancer (2011) - <AUTHOR> http://pages.citebite.com/b2x0j8q1megb <comment><AUTHOR> Folks, why are you upvoting this?

It only talks about CPU usage, Node not being Unixy enough, and Javascript being terrible.

A better critique would have included talks about callback hell, or the general philosophical issues of non-block/evented work versus synchronous programming: see the classic [http://www.youtube.com/watch?v=bzkRVzciAZg](http://www.youtube.com/watch?v=bzkRVzciAZg) .

This isn't even that great a rant.

(I appreciate my fellow Rails devs probably upvoting it out of spite, but c'mon...)

<comment><USER2> > Folks, why are you upvoting this?

Mostly, because it's funny. What's even funnier is how people take this sort of stuff _personally_.

I use Node, I know its limitations. I also use PHP. And Ruby. And Python. I use everything. I like having a full toolbox.

These languages are just that. Tools. If you went up to a carpenter and made fun of his hammer, do you really think he'll be pissed? He knows what his hammer is capable of and doesn't need anyone else to tell him.

A better question would be why this sort of commentary starts flame wars?

<comment><USER3> This is not directed at your comment individually, nor is it anything about your content in particular... but IF I HAVE TO HEAR THE TOOL/TOOLSET ANALOGY ONE MORE TIME to describe programming languages, I think I will... be disappointed in your lack of creativity. Really, don't you guys have any other analogies in your "toolbox"?

<comment><USER4> It's not even that great an analogy. If I use a particular hammer to build a table then I could throw it away at the end because it is no longer important as long as the nails are in the right place. I could even use a different hammer to drive every single nail if I wanted to and it wouldn't matter.

Languages , libraries , frameworks and runtimes on the other hand literally become a part of the end product. In many (maybe most) programs the total LOC count for the project is dominated by third party code vs original work.

So in this case they are not the tools, they are the nails.

<comment><USER5> Some analogies are more robust than others. But all analogies snap when stretched too far. I think this is one of those cases where you unfairly stretched it too far.

hammer : painting :: tool : finished_product

Though cliche, it's not like the analogy is misleading. Nails might not be "tools" since they can't normally be used on the next project, like a hammer can. But nails are still _a means_ to _an end_ , e.g. "hang painting on wall". If we really wanted to, we could stretch the analogy ad infinitum. "What's the nail represent? What's the room represent? Who bought the painting? etc." But the purpose of an analogy isn't to draw parallels between the objects' irrelevant particulars. Its purpose is to abstract from the objects an equivalency of relationship (i.e. means/end). In this case, I think the equivalency is preserved even after we extended our analogy in ways it was never intended to be.

<comment><USER4> It depends on the point that you are using the analogy to support. The tool analogy often gets trotted out to make an argument about something like language or framework choice not being important to the success of a project, but I think that the analogy becomes very brittle here for the reasons stated.

Deciding to switch something like a hammer (or text editor) mid project is likely not a big deal but switching to another language or framework can be an ordeal that requires planning. Since software projects are almost never "done" until they are obsolete the choice of language can have significant implications down the road that you wouldn't have if it was simply a "tool".

<comment><USER5> I think I understand what you're saying now. My mistake was reading "the tool analogy is undeservingly cliche/popular because it's rarely accurate" vs "the tool analogy is doesn't apply _in this instance_ (to programming languages) because hammers don't have lasting side effects".

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I clicked the link and wondered why the author appears to have deleted the original post.

"I kinda remember this guy," I thought to myself. "Let me read what else he has to say."

Then I found this: [http://teddziuba.com/post/24585610978/starting- over](http://teddziuba.com/post/24585610978/starting-over)

Maybe he just didn't want to import his old posts into Tumblr somehow. Or maybe something else.

I dunno. Just thinking.

<comment><USER7> It's like how a super-villain goes evil, but not at all. I miss his brother...

</comment></comment><comment><USER8> TL;DR OP knows very little about cancer...

<comment><USER9> Thanks for the laugh.

</comment></comment><comment><USER10> I'm more disturbed by these comments that are pro trolling. I personally like to have thought out technical discussions without hyperbolic yelling, but I guess that's just me.

</comment><comment><USER11> I've never worked with Node and probably never will, but it's pretty dishonest to conflate the sense of "blocking" as in "postponed execution" with "blocking" as in "executing an intensive CPU-bound job" to make a point that shouldn't be surprising to anyone who's paying attention.

</comment><comment><USER12> This article does not do justice to Node and it is not even an accurate criticism of Node.

I can provide similar arguments about PHP, Ruby, Python as well as JAVA and say they are cancer too but they are not. Every technology has its limitations but there is no doubt that NodeJS has opened up many new possibilities when it comes to doing thing on web. It will never be able to do everything that say JAVA does but it will always do a few things lot better than say Java or Ruby.

A good developer will always pick the best tool for the job without being "emotionally attached" to any one tool.

I will also not criticize those who are doing crazy things like writing a JVM using javascript. These people are pushing the limits, faster we reach those limits it is better for the rest of the community.

</comment><comment><USER13> Every month this hits the front page of HN, and each time it's less and less relevant.

</comment><comment><USER14> Not really anything useful in this article. To make fibonacci "non-blocking", you use process.nextTick callbacks to "interweave" the computations, just like real threads!

</comment><comment><USER15> I think this post is certainly correct in addressing CPU issues, and certain problems with Javascript.

What it fails to recognize however is that the "how" of Node.js isn't the cool part about node. The cool part is the "what" which is bridging the gap between the client and the server. This is the reason that people tolerate writing more javascript, not because everone loves javascript.

<comment><USER16> >The cool part is the "what" which is bridging the gap between the client and the server.

This is what loses me- how is that cool or good? I would much rather write a static html/css/angular frontend and have it talk to a Go webservice on my server. I want to use the best language for the client and server side, why do I care if they are the same? I want them to be basically completely independent apps where I could replace one or the other with a new implementation.

<comment><USER17> True, but there are cases when having the same language both sides can save some time, like validation routines for example. Not always appropriate, but can be a leg up on a project.

</comment></comment></comment><comment><USER18> I'm a little confused about this. He complains about Node violating separation of responsibility, and then about putting HTTP servers in front of Node. Would anyone with more sysadmin experience mind explaining what the drawbacks of this approach are compared to a more traditional setup?

</comment><comment><USER19> (2011)

I'm curious what Ted's view on Node.js is now that it (and he) has matured a bit.

</comment><comment><USER20> My favorite sentence started with: "A long time ago, the original neckbeards decided..."

</comment><comment><USER21> It's nice to see the "is cancer" meme provide some variety to the all too common "considered harmful". It's more biological.

[http://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_c...](http://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_cancer/)

</comment><comment><USER7> Which do I dislike more? Ridiculous font scale for chepaly repsonsive design SEO roach blog posts which gives me scroll wheel tendonitis..

Or blissfully, unapologetically unformatted content?

<comment><USER22> You do realize this is an archived version of a Google cache, and all of the images/CSS referenced are all 404's as a result?

</comment></comment><comment><USER23> I don't agree with it; I think time is proving him wrong.

But that is hilariously written. I love a well-executed embittered screed.

</comment><comment><USER24> Hacker News jumped the shark xD</comment>


Ask HN: Topics for writing - <AUTHOR>

The more I progress in my career, the more I see how valuable having good communication skills can be.
As much as I hate to admit it, I see how easily it is to be brought on a project as a programmer, be told what to do, and carry it out. It is, on the other hand, much more difficult (and to some degree) much more valuable to a) have knowledge in the domain you're programming in and b) an ability to efficiently communicate this knowledge to others.
My question to all of you is: how do you improve your skills as a writer. If I were to begin a blog, for example, I wouldn't even know what to write about. And then, even if I did, I wouldn't really have an audience to provide feedback.
The only thing I can think of is taking writing classes at JC at night, but I would rather try something new.
Thanks for your input. <comment><USER2> I'm a professional writer and editor. I regularly hire technology experts like you to explain things to other tech experts.

There are several paths you can follow. I would start out by writing for yourself, first. That could be a blog or even a daily journal. (The Artist's Way by Julia Cameron is recommended.) At this point don't worry about what to write; just get yourself into the habit of articulating your thoughts. Nobody needs to see this, just as they don't need to see your first Hello World efforts with a new programming language. It's okay to fail. In fact, it's necessary.

Another reason to write first for yourself is to discover what you like to write and what you're good at. (Ideally these overlap!) By writing for myself, first (originally in computer user group newsletters) I taught myself how to write a product review, and if I say so myself I became damned good at it. (Well, I don't have to say so myself; these days I'm a top reviewer on Amazon, and it's just a hobby.) You might discover that you like doing "follow the bouncing ball" how-to articles, or that you find them painfully difficult. You may discover a fondness for writing round-up articles (5 bug tracking tools) or reviews of programming books. Or a really effective rant. Whatever... the point is that you should try to write in different categories.

It won't take long before you begin to recognize your writing weaknesses, even if you don't know how to fix them yet. Again, like software development: You could realize that you tend to write software with memory leaks, even if you don't know the skills to fix it yet. But seeing what needs to be improved -- at least in your own head -- is important. Because if you think you're perfect, you won't learn from others.

Only then should you start to get feedback.

Whew, this is already pretty long. Let me know if it's on the right track, and I'll keep going.

<comment><AUTHOR> Wow this is great advice thank you. By all means, if time permits please keep going.

As as an aside, I've always suffered from a lack of "intrinsic" motivation for things - hence my desire for an audience to keep me honest so to speak. But I agree, it might be a better use of everyone's time to workout the initial kinks worked out on my own first.

Thanks again.

<comment><USER2> Okay, I'll go on for a little longer.

One thing to keep in mind is your goal in writing. There are people who want to write (or at least to have-written-something), and they don't care if the manuscript languishes in a drawer. There are folks who want to be published: to see their byline on a page. And there are people who want to earn money (ideally a living) from their writing.

All of these are fine goals. None is better than another. But you will find that writers in one category look down on those in another. Those of us who earn a living from our wordcrafting sometimes can sneer at those who would write for free, for instance. Don't let this bother you.

But _do_ pay attention to what your goals are... or how they develop. (This is something you may learn about yourself as you do your "writing just for me" process.) Because your goals, naturally, shape the manner in which you guide your own writing and related skills. That is, if you'd like to earn a bit of money from writing eventually, then you have to think in terms of getting attention from editors ( __cough __like me), and marketing, and writing about topics that someone might pay for. If you only want to be a better writer because it 'll help you become a better programmer (because it never hurts to communicate better!) that's a different set of choices.

</comment></comment></comment><comment><USER3> Your already have an audience. Your co-workers at your office, start an initiative like "know PHP" or "Email writing". Send out weekly e-mailers on it. Get feedback from your boss and co-workers. You communicate and you get feedback.

<comment><AUTHOR> Interesting idea, thanks.

</comment></comment><comment><USER4> I recently started my own blog and my biggest worry was finding a subject. I realized that when I write just one post I get ideas for my next one and as tempted as I get to published all in a day I try to follow my regular schedule. There are times were I spend a full week without writing but it doesn't bring me down cause I know sometimes it takes time to find the right subject.

My main reason for the blog was to improve my writing and 30 posts later I can already see the difference.</comment>


Popular startup stole my code – now what? - <AUTHOR> Hi, I want to ask HN for advice - a somewhat popular startup recently took a page straight out of Dilbert. Is this common? Should I do something about that?
I went on an interview at flipps.com and wrote some "sample" code to fix their horrible, memory-hungry iOS app. I only improved a single view of the app(because I suspected something like this might happen).
The company didn't wish to move forward and hire me to fix the rest of the app. I didn't think much of it and thought that was the end of that.
But to my surprise they immediately shipped my sample code to production! Now, I am aware of the legal status of code written as a "sample" and they probably don't owe me money for it.
I'm not looking for vengeance, and I'm not really all that angry. There's more code where that came from and I won't starve without their business. But this an unethical way to go about software development.
And it is especially dishonest toward their investors(who think they've made an investment in a technologically-savvy company, not just software thieves).
If you wish to drop them a line, the site is flipps.com, and their main investor is http://launchhub.com. <comment><USER2> Wait until they are close to exiting and then threaten to sue for 5%, settle for 2%. It's the absolute worst timing for a startup to get hit with something like this.

Of course, only do it if you're actually in the right, so check with a lawyer first.

<comment><USER3> Indeed. At any investment event, they're exquisitely vulnerable to the threat of a lawsuit.

</comment></comment><comment><USER4> In all honesty it's probably not worth pursuing. It's unethical and if they operate other parts of their business this way one can only hope they eventually implode.

I had a similar experience. I founded a company 3 years ago where we open source the majority of what we do. We entered into a discussion with a well funded (>$40M) "startup" about how they could use our service as a whitelabeled SaaS offering to their customers.

After a few promising exchanges including a Skype call with their Founder and VP of Engineering they stopped returning all of my attempts to see what the next steps should be. Turns out the reason was because they forked a private repository of the work we did - web, iOS and Android.

We found out they're using our code because they didn't even bother taking out our Crashalytics code and we started to get a bunch of pings. To this day their iOS app still uses our "yellow" color for toggle buttons.

[https://www.dropbox.com/s/dcpbbnbltm2bmq6/Photo%20Mar%2026%2...](https://www.dropbox.com/s/dcpbbnbltm2bmq6/Photo%20Mar%2026%2C%203%2013%2004%20PM.png)

They didn't violate any terms of our license (MIT) but I lost some faith in humanity because of what they did :).

\--

My company is Trovebox - code @ [https://github.com/photo](https://github.com/photo)

<comment><USER5> I don't get it, this isn't similar at all. Why did you lose faith in humanity because they did exactly what you told them they could do?

> our license (MIT)

Why did you MIT your code if you didn't want this to happen?

GPL exists for the exact reason you're bringing up here.

Sorry I don't mean this to be negative in anyway, I just don't get the thought pattern here.

Disclaimer: fan of bsd/mit/asl style licenses, feel gpl is better suited for things which need protection from the big players and enforce participation.

While I can understand your pain I feel it is a necessary pain for the greater good to have unrestrictive open source. (companies can always donate/contribute in other ways after the fact etc)

<comment><USER4> It is similar because of how it happened. There are lots of people using the code for various reasons and many of them participate in the community or contribute patches.

No one else that I know of has engaged in a conversation and then refused to reply to any further correspondence while at the same time asking questions to the community under pseudonyms.

Like the OP what the other company did was probably legal. That doesn't make something okay or right. Likewise (as I admitted) this other company didn't break any laws. But that wasn't the point.

You know what would have been okay? If they said, "look, we have some engineers that are going to have a go with the code - let's keep in touch" or "we are going to fork the code but will submit patches back". That is the spirit of the MIT license. Be civil.

Hope that doesn't come off as negative either :).

</comment></comment></comment><comment><USER6> Not a single Engineer on their team [http://www.flipps.com/flipps- team/](http://www.flipps.com/flipps-team/) \- such overhead.

<comment><USER7> what is a CAO anyway?

<comment><USER8> Chief Administrative Officer [http://en.m.wikipedia.org/wiki/Chief_administrative_officer](http://en.m.wikipedia.org/wiki/Chief_administrative_officer)

That position existed at my company several years ago before being acquired. Rumor was it used to be a more popular position back in the day. The company was over 100 years old.

</comment></comment></comment><comment><USER9> To be honest I would just keep clam and carry on. I really doubt you can do anything about it.

Why?

Proof. You say they took your code but whats to say they already had something similar in development. Without actually seeing the code changes you are just making assumptions (although it does sound suspicious).

Personally I would say take the moral high ground. Just forget it and move on. A lawyer will take you money and you will probably be worse off than before.

<comment><USER10> _> >To be honest I would just keep clam and carry on..._

Yes. In times of stress, I too often seek solace in mollusc husbandry.

</comment></comment><comment><USER11> If you didn't sign an NDA when you interviewed post your code fix here or on your blog. That should bring some visibility to your "cause". Otherwise it is your word against theirs.

<comment><AUTHOR> Here are the parts not covered by an NDA:

* Our initial email communication.

* The description of my task.

* The schedule for our meeting (in-office, where the code was written)

* The bill that my consulting company sent them, including a detailed description of the issue and the applied fix.

* Their refusal to continue working with my company.

* Their shipping of a new version two days after the interview.

I know it's all circumstantial. That's why the title doesn't say "I'm starting legal action against a popular startup".

Again, I'm not out for blood. But I _do_ want to spread the word and raise awareness.

</comment></comment><comment><USER12> Wow that looks like the most boring, un-inspiring group of people I've ever seen. You are a lucky man (or woman) to have walked away without a job.

</comment><comment><USER13> How do you know they shipped your code?

<comment><AUTHOR> Because it was shipped about 48 hours after I wrote it, and I see details in it that are specific to my implementation.

In fact, if you use their iOS app(especially on the more memory-consuming devices like an iPad Retina)you'll notice that the app reproducibly crashes on _all_ screens. Except one.

<comment><USER14> "reproducibly crashes on all screens. Except one"

This reminds me of the story about a large telecom company in North America and one in China. They were able to show that their code was stolen because they had the same bug.

<comment><USER15> Exactly. My product was stolen by a competitor. In court I could show their product had the same bug as mine. That was the start of their downfall. They bankrupted.

</comment></comment></comment></comment><comment><USER16> A popular startup once stole some content I created, but I decided it wasn't an amount that was worth suing over right then.

</comment><comment><USER17> What bothers me is that there are no technical people on their "team" page. Only an "R&D manager".

<comment><USER18> I counted four CS majors on their page...

</comment></comment><comment><USER19> I don't understand why a company would expose their source code to a job applicant who was not yet hired?

</comment><comment><USER20> You have their email, how long was the interview? Just send them an invoice for your typical hourly rate...

<comment><AUTHOR> I did, but they just said they are not interested and paid nothing. The whole thing took most of a work day, all of it spent writing code.

<comment><USER21> Can I ask why you agreed to spend "most of a work day" on a "sample"? I have heard others saying they spent a "few" hours on a technical test but I think most of a work day triggers alarms for me.

</comment></comment></comment><comment><USER22> How are you sure they shipped an update with your code</comment>


RIM's Playbook: Pricing under $500 and a big bet on Flash - <AUTHOR> http://www.zdnet.com/blog/btl/rims-playbook-pricing-under-500-and-a-big-bet-on-flash/41468

<comment><AUTHOR> As a former Flash developer I'm quite used to having to work around Flash's relatively lackluster performance, and I'm rather surprised that RIM has decided to bet on Flash/AIR for their tablet's app platform.

On the other hand, they automatically bring on board a massive population of Flash developers that are already familiar with the platform.

I suppose only time will tell whether this was the right move.</comment>


Nvidia Optimus support for Linux - <AUTHOR> https://github.com/MrMEEE/bumblebee <comment><USER2> I still can't believe Nvidia didn't do this themselves.

Last year for the first time ever, I specifically refused to buy a laptop with Nvidia. I didn't want to spend money on a discrete graphics card that I wouldn't be able to use.

<comment><USER3> We should note that nvidia has rewritten huge chunks of X internally (and that the blob provides these rewritten pieces), X isn't designed to support this kind of thing in the first place, big distros have plans to move off of X in the semi-near future (1 yr+, but still relatively short amount of value for the investment if we assume X will begin to fall into disuse) and the move to Wayland will impose significant development overhead on nvidia anyway (since Wayland requires KMS, which nvidia doesn't currently support), and nvidia has been looking for extra Linux developers for a long time without luck (see job listing at <http://www.nvnews.net/vbulletin/showthread.php?t=61644> ). Also consider that nvidia's primary market for Linux is big workstations, etc. (with OpenCL emerging), a field where Optimus support is not relevant.

I have also been disappointed to see poor support for Optimus and related techs on Linux but when you look at the costs involved it's not too surprising that nvidia would be reluctant to implement support in its existing blob for the existing infrastructure. Fingers crossed that they're working on it for the Wayland/KMS timeframe.

<comment><USER4> Somewhat off topic, but do you know why KMS seems to be such a big hurdle for the 3d video vendors' drivers? ATI's binery blob driver also doesn't support KMS even though they seem to actively develop it. The open source radeon driver does, but it doesn't support a sufficient amount of OpenGL to allow commercial native linux games or wine+directx games to run.

On the surface it doesn't seem like KMS support would be a big problem for people otherwise building complex graphics drivers.

As an aside, I use a laptop with AMD's switchable graphics solution. You can set and forget it to either setting rather well, but if you actually try switching back and forth you start running into tons of bugs, instabilities, usability problems etc.

</comment></comment></comment><comment><USER5> Can this thing shutdown Nvidia GPU to save battery and can this be used to run Unity.

I ask this because I got a laptop recently without proper research as Nvidia seem to release there drivers to linux, which they did but without Optimus support.</comment>


GUM: A better CLI for Git - <AUTHOR> http://www.saintsjd.com/2012/01/a-better-ui-for-git/ <comment><USER2> This is such a great idea. I'm using Git for my own repositories and I find myself doing searches for things like "how to undo a stage" or "how to revert a file" so often that it almost takes as much time to use Git as it does to do my programming.

No doubt Git gods who have every nuance of the system memorized can take advantage of the flexibility of the (IMHO) complicated and obtuse CLI. But for schmucks like me who just want to get work done and not worry about it, something like this would be a godsend.

I've more than once thought about switching away from Git just because I'm scared I'll do the wrong command and mess something up--and I've been programming for 15 years.

<comment><USER3> Not that the git UI doesn't leave a lot to be desired, but git has a nice security blanket:

git reflog

Now you can feel free rebase with abandon.

<comment><USER4> If you start depending on reflog just remember that changes in there are subject to garbage collection. Commits can be permanently deleted after they are 2 weeks old (by the default settings), so that's how long you can depend on them staying alive in the reflog.

Of course you can always give a branch name or tag to any commit to keep it alive too.

<comment><USER5> Two weeks isn't bad for an undo feature.

</comment></comment></comment></comment><comment><USER6> This is probably going to be a fairly unpopular opinion, since it seems git has won the popularity contest, but this is why I've always preferred bzr. Sure, it's a bit slower, but the interface is consistent. There aren't as many commands and they generally do the same thing every time. There aren't many switches on those commands either, besides the necessities, like defining revision numbers to apply the commands to.

I started using git about 6 months ago, primarily for github, and it's obviously a very powerful tool. Unfortunately, all that time that is generally saved by git's speed gets sunk into browsing around trying to understand how to use it. I have about 15 git projects right now and I still have no idea how to do some of the simplest things with git.

Maybe it's just because I came from years of svn, but I pretty much had bzr's interface figured out within a week. That whole week, I searched around for commands and whatnot and since then, it's been Incredibly rare for me to wonder what commands do what.

I'm not saying you should switch, as git is certainly an incredible tool. But if you live your life in the CLI, I would recommend trying bzr out. The simple interface is a dream in comparison.

Personally, if it weren't for github, I probably wouldn't use git at all for my own projects. That said, I may end up switching to git Because of github. And that's pretty much the only reason. Git's won the popularity contest an hence has a far larger ecosystem. But if I do make that switch, and that's a huge "if", I would miss bzr's CLI about as much as I miss childhood.

<comment><USER7> I used to use bzr too, then I switched to git because of the speed, and then to hg because git is impenetrable. Still, I miss bzr's ease of use and features (like any kind of branch you want).

I don't know why it's not as popular, it certainly deserves to be. I've had more frustrations in my short stints with git and hg than I ever had with bzr, and I don't think it's just because I know it better. For example, hg just pops up a vimdiff window for updating and then just leaves me stranded in a place I still don't know when I :q it in fear. bzr just gave me three files, .base, .mine, .other and left me to do whatever I wanted with it and commit whenever I'm comfortable.

I might just switch back to bzr again, I'm certainly losing more time now than I used to lose waiting for bzr to do its thing, and maybe it got faster now.

About git, why not use bzr-git? It worked wonderfully when I was using it.

<comment><USER6> I started out with bzr-git a long time ago for small one-off projects where I wasn't getting too deep into the process. Well, that's not true, when I First dug into DVCS, I tried all three, and since I was on windows back then (all- linux, now), git failed early, as since it didn't have a native windows version. Later on, when I didn't necessarily have time to learn git due to short deadlines, I tried bzr-git a few times.

I don't have _real_ answer, besides that it doesn't "feel right" to use another tool on a git repo. I _want_ to know git better. It's just not very easy to learn without fully committing to it.

As for bzr, there have definitely been speed improvements in the past couple years. I can't say how much faster, as I'm used to it. The Only times I notice things running slowly are when branching a large remote repo for the first time and when my system is completely maxed (currently working on a dynamic video-generation project). Otherwise, I barely notice. And besides, how often does one actually wait for a return prompt when checking in? `bzr ci -m "whatever"` and alt-tab back to whatever I'm working on.

* editing for clarification

<comment><USER7> Well, I prefer to work in vim, so the speed with which my VCS does things is pretty important. Other than that, screw it, I just switched back to bzr. Both hg and bzr have very good git interoperability, so now I can use whichever of the three VCSes I like, even for the same working tree (I can have .git, .hg and .bzr in the same working tree, all updated, and push whichever I like).

I'm already enjoying bzr again, though. I also would like to learn git, but I have a startup to launch, and I don't think git is worth the (pretty big) effort at this stage.

</comment></comment></comment></comment><comment><USER8> Most of this stuff can be done with aliases.

git stage

      git config alias.stage '!f () { if (( $# > 0 )); then git add -- "$@"; else git add -u; fi }; f'

git unstage

      git config alias.unstage 'reset --'

git undo is too ill-defind to actually implement. Sounds like the author wants it to be `git reset --hard HEAD`, but it's far more dangerous doing that while termed `git undo` than it is while termed `git reset --hard HEAD`, because people will have unrealistic expectations of what it does.

What's wrong with `git rm`? Here's a hint: you don't need to use it. Most people I know just delete the files however they want, and then run something like `git add -u` to pick up the deletions. That's exactly what the author is suggesting, but that's what people do today, so I don't see the issue.

As for git status, there's already a --short (or -s) flag that gives a very terse output. I personally use that all the time with an alias `git config alias.st 'status -sb'`.

Automatic setup? Put that info in the global config file. If git had to prompt for it, it would naturally place that info in the per-repo config file (absolutely would not make sense to automatically modify the global one), and it would be more confusing to users to be constantly re-prompted for name/email (because they switched repos). I don't see the problem with just telling new users to set up name/email globally, which every git tutorial I've seen does.

git switch

      git config alias.switch checkout

For git diff confusion, just use aliases for different commands. Do not make me type STAGE, that's no friendlier to users. I personally run with the following two aliases:

      git config alias.staged 'diff --cached'
      git config alias.unstaged 'diff'

though I rarely use the `git unstaged` command. I also have

      git config alias.both 'diff HEAD'

though I never use this one. Perhaps other names can be chosen that the author likes better.

The bit about deleting branches is misguided. `git remote` is a command that has sub-commands. `git branch` isn't. I understand that the author thinks having two styles of commands is weird, but there's not really a good alternative. Commands like `git remote` that have sub-commands would not work very well at all in the switch model (for a pathalogical example try to imagine what `git svn` would look like this way), and switch-based commands, which is most commands in git (and most commands in UNIX in general) would not do well in the sub-command model.

<comment><USER9> >Automatic setup? Put that info in the global config file. If git had to prompt for it, it would naturally place that info in the per-repo config file (absolutely would not make sense to automatically modify the global one)

You're thinking of implementation details, but prompting for and placing the info into ~/.gitconfig is what a newbie git user almost always wants. What's wrong with doing this?

<comment><USER8> Because it will completely screw with anyone who actually wants it in the per- repo config file. If I'm new to git, and my first usage is on a sample project, and git prompts me then I'll put in my personal contact information. But then if I go and start working on my company's git project, it will never prompt me again and I'll accidentally be committing company code under my personal email address. And I would be perfectly justified in blaming git's faulty user interface for letting that happen. At least if I set the config myself I _know_ I'm placing it in the global config file.

<comment><USER9> Your use case makes sense, but

1) Git's current initial setup UI would not prevent the user from making that mistake. It might make them feel stupid when they remember, but that's not the same thing as usability. The commit interface displays your identity and might throw up a red light.

2) Having made this mistake, a new user isn't going to remember the "git config" or "git commit --amend" commands they copied when prompted (if they remember entering them at all; I didn't remember exactly how initial setup worked). They're going to have to go look them up anyway.

3) Every user of Git will have a global username/email. Not every user will set them on a per-repo basis.

I guess I'm wondering why Git inconveniences everyone in deference to the less common use case.

<comment><USER8> In the common case, a lack of username/email actually indicates a configuration error. Blindly offering to set username/email may cause people to "fix" their config by re-setting username/email when in fact the lack of this is indicative of some other issue. Sure, _everybody_ sets up git once, but on the other hand, everybody sets up git _once_. The common use case is, by far, running with git already configured.

<comment><USER9> In the absence of a ~/.gitconf file, how is offering to set username/email more damaging than instructing the user to set them manually?

If the user doesn't think something is odd when the program wants initial setup info again, there's no helping them either way.

<comment><USER8> If the user needs the prompt to be able to set up user/email, then they're probably not qualified to diagnose what went wrong with their setup if something does go wrong. This way they can get help and fix whatever actually went wrong, rather than just re-setting their username/email and then discovering later that they lost all of their other configuration too.

Users that are capable of diagnosing what went wrong with their repo are also comfortable setting username/email in the config.

<comment><USER10> This sounds horribly elitist. You absolutely must use the command line and an editor in order to use git? Sure, I guess. If you get to spend all day working with neckbeards.

For the rest of us, having a pretty UI helps. And I don't see how is being user friendly and offering to _just do it_ can ever be a bad thing. Especially when the alternative is forcing people to figure out how a config file works. Should it be in ~/.gitconfiguration? ~/.gitconfig? Whats that . mean? That ~? A typo'd and it gets made it in ~/.gticonfig..

I have some stuff in my gitconfig that I like having, but, would never be able to figure it out if someone didn't A. tell me what to do or B. make a script that did it for me. And no, I didn't enjoy reading dozens of git manpages to try and find what I wanted. It really sucked.

<comment><USER8> You seem confused. If you want a pretty UI, what the hell are you doing on the command line? Go grab one of the half-dozen Git GUI apps out there. There's a few decent ones out these days, and they'll handle things like setting up your name/email.

<comment><USER10> Where's this rule that just because it is text based means that it has to be ugly? I seem to have missed the memo on it.

<comment><USER8> You're arguing in favor of having a "pretty UI" _at the expense_ of functionality. That's absolutely inappropriate for a command-line tool, especially one that was originally designed for use by hard-core computer programmers. If you want a pretty UI, go use a tool that wraps Git and provides one, like I just suggested. Sure, if you want to suggest that Git's error upon not having a username/email is made a bit friendlier, that's a reasonable suggestion. But you're suggesting something which would actually be a negative change for a lot of people (i.e. changing a hard error into a potential data loss situation).

<comment><USER11> Here is how I read this thread - someone links to a tool that wraps git with a prettier command line UI, you say that you don't need that, here's some magical aliases, others say but those aren't pretty like the tool we were originally discussing, you say "if you want a pretty UI, go use a tool that wraps Git and provides one" ...like the one from the original link? I don't get your argument, is there a reasonable place for prettier UIs wrapping common Git commands, or do we all just need to be more hardcore and learn to write good aliases?

<comment><USER8> Did you even read the OP? There is no tool. It's a blog post with a wish list for a magical tool that the author wants someone to create. Try reading the article next time before you go argue in the comments.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> Why this is needed:

Latest blog article over at progit.org: "Reset demystified" <http://progit.org/2011/07/11/reset.html>

Scott Chacon, author of the the Pro Git book, admits there that he didn't cover the "reset" command in depth in the book because he didn't fully understand it. Go figure...

</comment><comment><USER13> I quite like the idea, primarily because it would keep actions 'sounding like' what they affect. stage and unstage being the primary examples. Yeah, 'add' and 'reset' work, and fit other semantics, but when everything else refers to something you've added as something you've staged? Unnecessary cognitive friction. Add is largely useful for migrating from CVS/SVN/etc, but why not both with some porcelains?

That said, take the time and learn what git _does_ and how it works and it makes a _ton_ of sense. It's remarkably simple, and then the commands map directly to what you're doing to your history, which is utterly fantastic.

</comment><comment><USER14> While this may be a nice idea, I don't know if it improves the situation. Improving the situation means tackling the entire problem, top-to-bottom.

[http://thread.gmane.org/gmane.comp.version- control.git/18582...](http://thread.gmane.org/gmane.comp.version- control.git/185825/focus=185863)

[http://thread.gmane.org/gmane.comp.version- control.git/17506...](http://thread.gmane.org/gmane.comp.version- control.git/175061)

Quoting Junio, the git maintainer:

"""Rc or not rc, just repeating a fuzzy and uncooked "idea" around phoney ref- looking names that will end up confusing the users, and selling that as if it is a logical conclusion to "we want to give an easier to understand UI", without presenting a solid user experience design that is convincing enough that the "idea" will reduce confusion will not get us anywhere"""

Here's the first example from the blog post:

        # Why not replace things like: git reset HEAD -- file with:
        > git unstage

What the author fails to realize is that you could have just said, "git reset file", which makes this `unstage` example much less convincing.

We actually do not recommend `git reset --hard` very often these days. `git checkout -f` is nicer alternative and is semantically related to `git checkout file`.

The 'stage' alias that adds and also understands deletions is a nice addition. It can be implemented as an alias. `git config --global alias.stage 'add -u --'`.

<comment><USER15> _> While this may be a nice idea, I don't know if it improves the situation. Improving the situation means tackling the entire problem, top-to-bottom._

First you have to define the problem.

To me, git feels like building blocks that you use to create your own versioning system and workflow: you learn the tool, you discover which features are useful to you and you use only those. Another person (or group) will use a different process and a different set of features, effectively creating a different version control system.

So, in my opinion, git tackles the problem of being the foundation to a wide range of different VCSs, and does a pretty good job at that.

Something like this is tackling a similar problem to git-flow. Tools like this, with less features but that define or suggest a workflow are very useful, because they remove the confusion while you learn the tool _and_ try to create your workflow at the same time, without knowing what the tool can do for you.

<comment><USER16> > _To me, git feels like building blocks that you use to create your own > versioning system and workflow_

That's because it is almost exactly that. It helps to go back and read the earliest discussions of it.

Linus didn't build a version control system. He never really intended to. He built "gitfs" and equivalents of mkfs, fsck, cd, rm, mv, cp, and a thousand other tools for manipulating it.

Unfortunately, they were also built rather specifically to Linus's mental model and the kernel's workflow, so they look pretty funny to everyone else.

It's getting better. The git of 2012 is a lot friendlier than the git of 2005. But the impedance mismatch between what Linus was building and what the rest of the world expects is a long way from being eliminated.

</comment></comment></comment><comment><USER17> Such a good idea. I mostly use Mercurial, which has a clean, logical and consistent CLI which I like a lot. And while I like the _concept_ of Git, using it makes my head hurt.

I'm reminded of the article that compares the two: Git is Wesley Snipes; Mercurial is Denzel Washington: <http://www.ericsink.com/entries/hg_denzel.html>.

</comment><comment><USER18> I expected much more from this, off the title.

Look, Git is a major pain in the ass because it's designed to support every possibly imaginable workflow. The only way to do this is to just expose Git's internals, i.e. make users think like Git, instead of making Git think like its users. This fits the minds of kernel hackers perfectly (they think like computers do all the time), so there's your history-of-Git in a one-liner as a free bonus.

The only way to make Git more usable is to make a frontend that carefully and in a well thought out way enforces a certain workflow. It'll be more usable for people who use that workflow, then (and, obviously, less usable once you want to step outside that workflow)

git-flow [1] is a nice example of this. I'd love to see more examples for additional workflows. I'm also very curious whether it's possible to do this without leaky abstractions, i.e. to really have a team up and running that doesn't understand anything about Git, and only understands the workflow. Did anyone using git flow manage that? (i.e. have devs never touch 'bare' git)

[1][<http://nvie.com/posts/a-successful-git-branching-model/>]

</comment><comment><USER19> This already exists. It's called EasyGit:

<http://people.gnome.org/~newren/eg/>

<comment><USER20> Elijah has a nice detailed breakdown of the EasyGit UI rationale as well: <http://people.gnome.org/~newren/eg/git-eg-differences.html>

I've been using EasyGit for years, it's very good and addresses exactly the complaint made in this article. Plus it's a one-file script so it's simple to drop it onto whatever computer you're using.

</comment></comment><comment><USER21> This is pretty nice. I totally concur with the post, and I think logical commands is the biggest (only?) benefit of Mercurial over Git... been using Legit by Kenneth Reitz lately... I recommend it highly <https://github.com/kennethreitz/legit>

</comment><comment><USER22> I've seen a few "better CLI for X" applications lately, I think there might be something there. Personally, I almost prefer cli at this point for lots of stuff, but a lot of it is still just so cryptic. It doesn't need to be.

Thinking about usability doesn't have to be limited to web apps, and it's refreshing to see some people starting to agree.

Edit: definitely not sure where a business would be for a product like that, such a niche market, and a market that doesn't like paying for things. But who knows?

</comment><comment><USER23> I think "git undo" would be even nicer if it was a generic undo and simply undid the last operation (only when possible of course; unpush might be slightly problematic).

Also I'm really tired of messing with ~/.gitmodules and unwieldy *submodule- commands that demand to be executed in the project-root all the time. Why can't we simply "git add" sub-repositories, perhaps bailing with a warning by default and an extra-flag to really do it...

<comment><USER24> Agreed! Treating submodules as their own git repositories is a neat and powerful idea, but the UI really does breakdown. Especially when adding a trailing "/" to the submodule name like: 'git add submodule_name/' will assume you are deleting it and adding the files recursively in the parent project.

</comment></comment><comment><USER25> Is it possible for all of these to be implemented as git command aliases?

<comment><USER26> Yes, this is what alias is for. You want a git unstage but cant remember what it was? Alias.

</comment></comment><comment><USER26> Where is this GUM or better cli for git? All I see is a README file containing the same thing as the webpost. Not to be a complainer, but there may be a reason the commands are the way they are and you cant simply change them without changing the implementation, perhaps you should look at alias to solve your memory problems.

<comment><USER27> Is there a reason, or was this just the way the commands evolved? If there is a reason, this would be the perfect time to point it out. Otherwise, what's wrong with improving the UI for everone?

[edit] but yeah, where's the code?

</comment></comment><comment><USER28> .gitconfig is your friend: <https://gist.github.com/1706237>

<comment><USER29> That looks useful, but some comments would be nice. What do u, ud, and prep do?

<comment><USER28> `git u $branch` checks out $branch, updates it against whatever remote it's synced to, and then attempts to rebase the current branch against it. `git ud $branch` does the same think, except it also performs the merge of the current branch onto $branch.

`git prep` Simply greps the commit for use of Python/JS print debugging statements, things that shouldn't make it into the codebase.

</comment></comment></comment><comment><USER30> I recently discovered that creating a script called git_command somewhere in your path makes this work:

      $ git command

Now these recommendations are easy to implement.

<comment><USER31> Some experimentation suggests that it's actually `git-command` (with a hyphen, not an underscore). This is consistent with the man pages, where, for example, one asks for `man git-add`.

EDIT: Not to take away from this handy tip, which I didn't know. I guess one can view it as a sort of souped-up alias.

<comment><USER30> Oops, that was a typo.

</comment></comment></comment><comment><USER32> I'm not sure I agree that it's necessarily bad if the interface is a side- effect of the implementation. It seems very worse-is-better to me.

I feel like when the interface is a side-effect of implementation, you get a more gradual sliding scale from user to developer (like being able to experiment with web apis by curling at them).

In git's case, I appreciate that I can trawl around through my .git directory and not get lost because it pretty closely matches the interface.

<comment><USER20> That said, I'm not sure UI matching the implementation is the problem with git's UI; it's more that git's UI is inconsistent, has poorly-chosen names for commands/options, and has bad default behaviors.

</comment></comment><comment><USER33> One problem of that thought it that it will make git commands even more obscure. I.e. when a user will have to use the real git cli, they will be totally lost. I'm not saying it's a bad idea, just something to think about when designing the new cli. Maybe try to stay consistent with the commands while still making them easier to remember and understand. For instance:

      git diff STAGE HEAD

seems a bit unconventional to me.

</comment><comment><USER34> Can I suggest that 'select' is used instead of 'stage'? After all, one is just selecting the files to be committed. Staging, although a legitimate use of the word, is a bit abstract I feel. I can't imagine anyone failing to understand the concept of selecting something.

</comment><comment><USER35> Make this even more intuitive by wrapping git (or gum) in a REPL:

<https://github.com/defunkt/repl>

I use this on a daily basis to avoid having to type "git" repetitively.

</comment><comment><USER36> Cool, I might try this to give Git a second chance, for now I am resorting to hg-git whenever I have to touch a git project. Sometimes it gets confused when I'm rewriting history on the hg side and pull from the git upstream but overall having a sane UI I feel confident about without googling before every command (or worse, limiting myself to a "safe" subset and using it almost like Subversion, as some of my coworkers) outweighs the occasional snafu.

<comment><USER37> Two things to remember about git: Once you commit something, you can always get it back via the reflog no matter what git commands you type. The second thing, you should expect to have to Google before every command if you want to understand _any_ software in detail. It's like saying, "I refuse to learn to play the piano because I don't already know how to do it." Well, yes. Listen to the radio then, but don't whine about how the piano has a terrible design.

</comment></comment><comment><USER38> This is similar to what I get with magit-mode in emacs. It's pretty slick.

<http://philjackson.github.com/magit/>

<comment><USER39> I came to post that. Magit has a very similar way of thinking about things, with commands being 'stage' and 'unstage' and a very simple revert, and nearly all commands work on chunks as well as on entire files. Nearly as much of a step up as using git was in the first place.

</comment></comment><comment><USER40> All I want for git is a "git motd" command that teaches you a little bit of the plumbing every time you run it.

And I will set it to execute when I login on a shell.

</comment><comment><USER41> I've noticed that making the mental switch from writing code to committing it costs quite of bit of time throughout a day of development. A more intuitive interface would remove the need to make the mental switch. This interface feels much more intuitive to me -- great job.

</comment><comment><USER42> There is no code on github

<https://github.com/saintsjd/gum>

but the idea sounds great!

</comment><comment><USER43> I like the instructions in git status. I usually follow them when I'm not sure of what to do.

</comment><comment><USER44> git status usually has a help command to unstage the change.

</comment><comment><USER45> I'm going to put my grumpy old man hat on for a second and say that if you don't understand how git works, then you shouldn't be using it. Go use svn or hg or something that has a simpler internal model, and good luck to you.

For me, gits internal model is simply not that hard, and I'm a run of the mill twenty-something year old developer who feels vaguely guilty about not knowing how fundamental data structures and algorithms work. It's a directed acyclic graph that points to items in a content addressable database. Between the progit book and the man pages, I had a pretty good conceptual model of it in an afternoon. I encourage anyone who actually wants to learn it to spend a little time with TFM and get it out of the way.

Otherwise, seriously, quit your whining. The CLI makes intuitive sense to me and I can manipulate the DAG without much mental effort. The worst case scenario is that you rebase public history, and `git help rebase` will tell you how to get yourself out of that mess.

<comment><USER46> I can appreciate the sentiment that Git's internal model is straightforward enough that the UI is justified in exposing it. However, you also have to consider the perspective of someone who sees a cool project, decides to contribute code, sees that that the project code is in a git repo, and says, "Ok, I'll learn the basics of git so I can contribute to this cool project." It's not fair to expect such a person to learn the whole data model of git and how all the commands map to it just so they can contribute a 5-line patch in the project's native VCS. So I think there's definitely a strong argument in favor of providing a porcelain for Git that is independent of its plumbing, even if that porcelain is only capable of some basic operations.

<comment><USER45> In that particular case, I'd be inclined to send over the patch as a diff file, though I can see the point your making.

<comment><USER46> Even if you just want to send a patch, in order to get the patch you need to run diff on the original file and the changed one. If you've already edited your copy, then in order to get a copy of the original you're back to either figuring out basic git usage or hoping that the source repo provides a web interface from which you can download it. Either way, without knowing how to use git the prospective contributor could easily get discouraged and give up.</comment></comment></comment></comment>


Ask HN: Instapaper for videos? - <AUTHOR>

Does anyone know of a simple app or bookmarklet, which I can use to save videos to watch later? <comment><USER2> radbox.me is an awesome one

<comment><AUTHOR> Thank you!</comment></comment>


Ask HN: What is your favorite editor and why? - <AUTHOR>

I've been using sublime and find it pretty useful but as I gain more programming skills, I thought it'd be worth the while to see what others use and why their editors may be 'better'.<p>I am looking for something that is obviously easy to use but also looking to see if there are any super smart editors out there? When I did a quick Google search, I found WebStorm but again, would like to hear more personal opinions on here. Thanks! <comment><USER2> begin flamewar in 5, 4, 3, 2, 1 ...

Seriously though, there are a number of historical posts about this (emacs vs vi being the oldest and best, almost as good as ninjas vs pirates, but I digress).

You should really list of all of your requirements and see if your editor of choice supports those requirements. That is the best solution, asking the internet for this, is like, well asking for someone's favorite editor. :D

Try to solve the problem of why you don't like your editor, rather than trying different editors to see if they 'fit'.

Me, I'm a vim man through and through, but it has everything I need to do my job. Find that, find zen!</comment>


Insanely fast, headless full-stack testing using Node.js - <AUTHOR> http://zombie.labnotes.org/

<comment><USER2> Has anyone tried this ? Looks like a good option to test front-end</comment>


New IBM CEO calls for a "maniacal focus" on AI and hybrid cloud - <AUTHOR> https://www.businessinsider.com/ibm-arvind-krishna-ceo-welcome-letter-ai-hybrid-cloud-2020-4 <comment><USER2> This is not going to end well. Is the plan to get bought out by Kodak or Atari?</comment>


Bleeding Edge HTML5 - <AUTHOR> http://kinlan-presentations.appspot.com/bleeding-berlin/index.html#1

<comment><USER2> I saw this presentation on the Google Developers Day, the WebRTC was working during the presentation.

</comment><comment><USER3> "webkitMediaSourceURL is not available"

Guess my latest Chromium isn't bleeding edge enough.

</comment><comment><USER4> I'm getting lots of "503 Service Unavailable".

</comment><comment><USER5> Doesn't work in Firefox or Chrome for me.

</comment><comment><USER6> the page is empty except for the js-alert telling me that "webkitMediaSourceURL is not available"</comment>


12:34 07/08/09 - <AUTHOR>

Today only - time clock as numbers from 1 to 9 <comment><USER2> i believe you mean:

12:34:56 7/8/09

it'll work better in another 81ish years.

<comment><AUTHOR> yeah, it was too early... anyway, who still counts seconds? :-)</comment></comment>


Why does Facebook change my link to translate.google.com? - <AUTHOR>

Hi.
Maybe it's just me, but whenever I try to put any link to translate.google.com (for instance http://translate.google.com/#en|cs|asaasa) I see this link on my board: http://translate.google.com/#en|cs|Suck%20my%20balls
Maybe I'm doing something wrong, but this looks weird, to say the least.
Best regards,<AUTHOR> <comment><USER2> This happened to me and a friend earlier today, but it seems the problem has been fixed.

</comment><comment><AUTHOR> Now it works just fine... Argh, probably just a stupid bug.

</comment><comment><USER3> Not sure what you're talking about to be honest.

<http://imgur.com/B7HAZ.png></comment>


Parable of the Polygons (2014) - <AUTHOR> http://ncase.me/polygons/ <comment><USER2> This might be malicious of me but I found another way to maintain an almost 0 % segregation in the polygon experiment. Turn the satisfaction threshold way up: "I'll move if less then 85% are like me". This resulted in constant movement.

But a different conclusion might be reached. Improve mobility (remote work, coworking spaces, high speed cheap eco friendly transportation, etc.) and the world might become more dynamic, and stable. This is a tech problem and it's something we can work on solving. Changing mentalities is not a tech problem. Imagine if we had the technology to move entire dwellings as easy as packing a suitcase. Even further, if we had teleportation, the notion of neighbourhood goes away, the entire world becomes your neighbour.

And lowering segregation by increasing mobility might result in gradually increasing tolerance (due to exposure), thereby further decreasing segregation.

Just my two cent ramblings.

</comment><comment><USER3> Is it bad to prefer to be around people with similar backgrounds and interests? Isn't this the definition of a community?

<comment><USER4> That is just one type of community.

<comment><USER3> What kind of community isn't centered around some form of shared values or common interests?

<comment><USER5> what about the original form of community: physical location -- the one we spent deep history evolving to be suited to navigate with wetware, instinct, intuition and body language, and from which initial social behaviour emerged :)

<comment><USER6> That clearly is not an answer the question asked.

</comment></comment></comment></comment></comment><comment><USER7> Doesn't really do a good job of addressing minorities. What if your ethnicity makes up 3-5% of an area, are you just expected to diffuse into the general population?

For example, I come from a relatively rural area and spent a few months working in Mountain View. At first i thought it was a proverial melting pot relative to home, but then i realized that i never saw any black folks...

Demographics for the area show African American at 2-3%. So if you happen to be black and get hired on at Google, for example, is there sonething wrong with looking for an area where you might relate to your neighbors more or should you optimize for diversity?

<comment><USER8> Isn't the whole point of integrating people together to create a melting pot where you end up with a homogenous society? If you create "perfect" neighbourhoods with a mix of all races then you'll end up losing individual identities over a few generations. Children will mix at school, couples will form and you get mixed families, and within a couple of generations, you're roughly homogenous.

The way to end racial discrimination is to end racial identities. Humans are always going to prefer people similar to themselves, so you need to make everyone similar.

<comment><USER9> > Humans are always going to prefer people similar to > themselves, so you > need to make everyone similar.

A very strong and potentially pernicious conclusion for such vague premises.

Wouldn't it be more accurate to say that humans feel reassured within their group(s) (whatever that is) and also sometime feel threatened by other groups? This behavior itself being worsened by social insecurity (giving signs of one's belonging to the in group by being hostile to the out group), as frequently documented.

Following this line of thoughts I don't think looking more similar would solve anything. It's not aiming at the problem and it's not even doable (we would have to look the same, speak the same, think the same, etc, or we would always be able to form groups).

<comment><USER8> I think you took the wrong conclusion from my comment. The whole point of mixing communities isn't for skin colour, it's to homogenise culture. Families will mix too but that is much slower than culture.

<comment><USER9> I was not thinking specifically about skin colour. You might still need to make clearer what you are thinking about, because to be honest homogenising culture sound even more impractical and hazardous than homogenising skin colour.

</comment></comment></comment></comment></comment><comment><USER10> If you're living around too many people who look similar to you, you should be unhappy and move somewhere else?

</comment><comment><USER11> Many previous submissions: [https://hn.algolia.com/?query=Parable%20of%20the%20Polygons&...](https://hn.algolia.com/?query=Parable%20of%20the%20Polygons&sort=byDate&dateRange=all&type=story&storyText=false&prefix&page=0)

But only one significant discussion: [https://news.ycombinator.com/item?id=8716538](https://news.ycombinator.com/item?id=8716538)

</comment><comment><USER12> I like Nicky Case's interactive systems. It's a way of bringing practical considerations to discussions which are usually more moral, and usually "more heat than light". It seems like it's useful for surfacing two kinds of disagreement: differences in the models people hold of the world, and differences in moral foundations about how to feel about that.

Models can be wrong, etc. but where disagreeing with someone's moral argument makes you 'bad', disagreeing with a practical argument is 'dumb'.

</comment><comment><USER13> Why is it inherently and obviously good to mix the polygons?

<comment><USER14> For some categories, it's probably harmless. I don't think we need to re-sort living arrangements until we have a proper diversity of sports fandom, for instance.

However, the most prominent understanding of "difference" in the western world is race. Racial hierarchies have led to unequal distribution of resources, unfairly balanced prospects for individuals and unequal representation in government. Arguably, race has been weaponized to disenfranchise a large number of human beings, only some of which are members of the "lesser" race. For instance, scholars have argued that racial hierarchies allowed landowners in the post-civil-war-south to avoid material compensation of their white workers because the workers were satisfied by the 'comparative gain' of being better off than working class african americans (who the same landowners paid even less).

<comment><USER15> Although your precise wording is correct ("prominent understanding"), far greater splits exist, for example, on political views and on income, and arguably even more harmful.

<comment><USER14> I focus on race because it's an entirely artificial construction. It makes sense that, say, communists and capitalists might want to live in different communities (and it's not clear it's a bad thing). There are also forces that combine to push people of different incomes into different areas that aren't related to a desire for cultural homogeneity.

P.s. If you're interested in how race is artificial this is a good read: [https://www.theatlantic.com/national/archive/2013/05/what- we...](https://www.theatlantic.com/national/archive/2013/05/what-we-mean-when- we-say-race-is-a-social-construct/275872/)

<comment><USER15> At least where I live, the segregation isn't on skin color, although it sure looks that way at first glance.

There are two major communities (African Americans and whites) and a number of smaller ones.

The "white" community actually refers to "WASPs and their descendants," but a number of other people get lumped in based on skin color. The AA community refers to descendants of slaves.

The two communities speak different dialects of English. They have drastically different communication patterns (when do you use last name versus first name? when is it okay to yell? how do you show respect?). They have different religious practices. They have different practices for raising kids. They work different jobs. They differ, significantly, on almost all cultural dimensions.

I see very little discrimination or desire to segregate based on skin color. If an Ghanian moves into the community, they're more likely to move into the white community than the African American one. Likewise with African Americans who grew up in WASP communities.

In practice, many immigrants -- of all skin colors including whites coming from places other than Western Europe -- tend to form their own community; they don't quite fit in in either the "white" and the "AA" community. Both communities accept a narrow range of behaviors as appropriate; the broader international community tends to give a bit more cultural leeway. A Nigerian, a Japanese, a Russian, and an Indian immigrant will interact with each other just fine, but quite often don't assimilate too well into either "white" or "AA" communities.

<comment><USER14> Distinct cultural communities that often, but don't always, correspond to ethnicity is exactly what you would expect from the construction of a "racial" hierarchy.

If we divided caucasian Americans into two groups, designated one group as "lesser," and then waited a few hundred years you would find similarly stark cultural differences. Again, race is entirely artificial. People were divided based only on superficial appearance and, once those divisions are enforced, cultural distance grows.

So, what you're experiencing is the outgrowth of a racial classification system. It's entirely artificial but, as you say, it also has _real_ consequences. Even if, by magic, we were all transformed to have the same ethnic heritage, the cultural legacy of "race" would make "race" very apparent. African American and caucasian American culture _is_ different - even though those differences are partially (largely? hard to say) from the racial structure imposed on African Americans.

The answer is in your final paragraph. Neither "white" or "AA" culture is a perfect fit for new arrivals (just ask Jamaicans or darker skinned Dominican ex-pats how well they feel seen by any American culture). Indeed, no single cultural approach is "right" and we do ourselves a disservice by searching for one. We have had structures and policies that have driven the two largest cultural groups (white and African American) apart for generations. Abating that push should be a high priority. We also need to be attentive to including as many cultural groups as possible in finding common ground and understanding for living together comfortably. All groups will need to "give" a little ground in terms of what they would most prefer and, in the interest of equity and facing history, many experts think caucasian Americans should give the most.</comment></comment></comment></comment></comment></comment>


Schedule C# code to run in the cloud - <AUTHOR> http://www.executify.com/

<comment><USER2> It is currently priced at $1.00 a minute of execution time. It is setup using cron scheduling. Any valid .NET code can run.

</comment><comment><USER3> Can you post expected pricing? and some documentation, please? Thanks!</comment>


Logging in with tattoos and pills may be a reality soon. - <AUTHOR> http://www.digitaltrends.com/mobile/log-in-password-with-electronic-tattoos-or-pills/

<comment><AUTHOR> >The other innovation unveiled is a pill that a user can swallow, which then switches on, powered by the person's stomach acid. The pill then transmits an 18-bit signal, essentially making the person a walking password.

I don't know how I feel about this one, nor do I understand how it would work. Do you have to do that every day? Every other day? How would the transmitter inside the pill actually stay in your body?</comment>


WhatsAPP backing up on Google Drive unencrypted? - <AUTHOR> I just clicked on What's App on my Android phone to send a message and then it asked me to backup my Chats (messages) and Media on Google Drive.
You have a choice (lucky enough there's NEVER in the selection). Why would I do that?! Am I the only one noticing this?! Like WTF!!
https://www.whatsapp.com/faq/en/android/28000019 Important: Media and messages you back up are not protected by WhatsApp end-to-end encryption while in Google Drive.
EDIT To ensure you are not backing up to your Google Drive:
+ Click on the three dots top right corner + Click on Settings + Click on Chats backup
There should be a Google Drive settings <comment><USER2> What's the point of encryption Google has everything anyway :/</comment>


Why Lisp is Awesome - <AUTHOR> http://atomized.org/2009/01/why-lisp-is-awesome/ <comment><USER2> This isn't why Lisp is awesome. This is why Lisp _was_ awesome, back 50 years ago. Every single one of these features has since been adopted by mainstream scripting languages. What still sets Lisp apart is its metalinguistic capability - macros (hygienic or not).

<comment><USER3> I was specifically writing about features Lisp pioneered which other languages adopted. I think it's enlightening to understand the roots and history of things, and fint it amazing that such an old language pioneered so many fundamental constructs.

Perhaps by 2059, we'll have languages with macros and regular syntax.

<comment><USER4> > Perhaps by 2059, we'll have languages with macros and regular syntax.

Boo has macros ... <http://boo.codehaus.org/Language+Guide> (at the end, under 'advanced features'.

<comment><USER5> C has macros.

</comment></comment></comment></comment><comment><USER6> Nitpick: "dyanmic programming" does not meant what you think it means. <http://en.wikipedia.org/wiki/Dynamic_programming>

</comment><comment><USER7> Risking being downmodded, I'd say Lisp is too "low level" for many common problems, which is great if your domain is parser/compiler construction/transformation/combination. I have no problem with lisp syntax (I can even tolerate C++ templates :), but it (and most general purpose languages) feels less natural for many domain specific problems than languages catering to the domains.

A DSL family based on a flexible core (with a lispish intermediate language even) might be a viable approach.

In many situations, simplicity and restrictions (constraints) in DSLs is better than flexibility and expressiveness in a general purpose language, because it can offer new possibilities for domain specific optimizations due to domain specific constraints.

Just like new notations in math led to breakthroughs in many math branches, new syntax can bring new life to software in many specific domains.

The key to such systems seems to be making DSLs easy to build and optimize using a suite of common building blocks (human (cs people) friendly intermediate languages (like lisp as opposed to VM byte codes) and libraries.)

<comment><USER5> That's why Lisp was called 'AI assembler'. Literally hundreds of higher-level languages have been implemented on top of Lisp. One of those has been integrated into Common Lisp: CLOS, a high-level object-oriented language for programming dynamic systems, with meta-programming capabilities.

<comment><USER7> Most of these "high-level" languages are more of "extensions" (CLOS certainly feels like an extension) or alternative lispish languages than bona fide DSLs with DS constraints (that can be used for DS optimizations). The S-expression syntax feels foreign/messy in many domains.

<comment><USER5> Languages on top of Lisp can be all from extensions, to languages with their own syntax, parser, compiler, ...

Examples for "high-level" languages on top of Lisp:

Macsyma, Axiom, Refine, AP5, RacerPro, CycL, NESL, Reduce, PVS, the original ML, ...

For a Lisp-like example see PDDL (Planning Domain Definition Language):

        (define (domain hanoi-domain)
                (:requirements :equality)
                (:predicates (disk ?x) (smaller ?x ?y) (on ?x ?y) (clear ?x))
                (:action move-disk
                 :parameters (?disk ?below-disk ?new-below-disk)
                 :precondition (and (disk ?disk)
                                    (smaller ?disk ?new-below-disk)
                                    (not (= ?new-below-disk ?below-disk))
                                    (not (= ?new-below-disk ?disk))
                                    (not (= ?below-disk ?disk))
                                    (on ?disk ?below-disk)
                                    (clear ?disk)
                                    (clear ?new-below-disk))
                 :effect (and (clear ?below-disk)
                              (on ?disk ?new-below-disk)
                              (not (on ?disk ?below-disk))
                              (not (clear ?new-below-disk)))))

Tools like these are widely used in logistics domains, one of the domains where Lisp has been widely used. There is a competition between planning systems and PDDL is being used to describe the problems.

For a non-s-expression domain specific language on top of Lisp see for example PWGL. It uses a graphical language. Also Macsyma/Maxima, and many many many others.

</comment></comment></comment></comment><comment><USER8> If anyone misses Geocities or myspace, look at this site in IE. I'm not sure what exactly the point of (seemingly) intentionally making your blog site readable in FF and outrageously hard to read in IE is...

<comment><USER3> I got tired of fixing layouts in IE and decided it would be more fun to break it instead.

<comment><USER8> That's certainly one approach.

From the outside, my interpretation of that is "I don't value my own opinion enough to make it accessible to users of other extremely common browsers."

I assume you blog because you feel like you have something to say that's worth reading. Making that content inaccessible to a very large segment of the browsers/users in the world works contrary to that. (I do sympathize with the PITA factor.)

</comment></comment></comment><comment><USER9> I wasn't aware you could use const char pointers in switch statements.

switch (var) {

        case "foo":
            printf("foo block.");
            break;

        case "bar":
            printf("bar block.");
            break;

        default:
            printf("Default case")
    }

<comment><USER10> You can't:

$ cat foo.c

        #include <stdio.h>
        main() {
            const char *foo = "bar";
            switch (foo) {
                case "foo":
                    printf("foo\n");
            }
        }

$ gcc -pedantic -std=c99 foo.c -o foo

        foo.c: In function 'main':
        foo.c:4: error: switch quantity not an integer
        foo.c:5: error: case label does not reduce to an integer constant

<comment><USER9> Sorry to make you put in so much work.

I'm aware that you can't do this.

I guess my sarcasm didn't translate:)

</comment></comment></comment><comment><USER11> Many of these features are actually quite common in other languages. For example, C# has lambdas, functions as first class objects, closures, dynamic programming, null coalescence etc. The real power of Lisp in my opinion is not the existence of these features but the way they perfectly fit into the S-Expression syntax.

<comment><USER12> Right. Mainstream languages have been gradually evolving towards Lisp but until they adopt a simple uniform syntax they won't get real macros, which I think is the biggest difference between Lisp and other languages today.

<comment><USER11> I believe that appreciating Lisp's minimalistic, tree-like syntax requires a very mathematical way of thinking. Many (perhaps most) developers have a different way of thinking. There's nothing wrong with that, diversity is a good thing but because of that, I don't think that the S-Expression syntax will ever become "mainstream".

<comment><USER5> It is already.

XML is full of prefix, nested syntax.

<comment><USER12> Yes, but nobody would seriously write a programming language that used XML for its syntax.

<comment><USER5> So you say existing XML-based programming languages were 'written' by non- serious people?

'Water':

        <defmethod test_true source=required="ek_string">
         <try <if> source.<execute_string/>.<not/>
                     <concat "Busted: "source/>.<print/>
                   else "OK"
              </if>

           >
          <concat "Errored: " source/>.<print/>
         </try>
       </defmethod>

See also XSLT, XL, RuleML, ...

<comment><USER12> _So you say existing XML-based programming languages were 'written' by non- serious people?_

Whether or not the people who wrote (sorry, I guess "designed" is the more appropriate word) these languages were serious, I do believe they are a dead- end.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> The "switch statement" in C is closer to the CASE macro[1] in Lisp.

[1]: [http://www.lispworks.com/documentation/HyperSpec/Body/m_case...](http://www.lispworks.com/documentation/HyperSpec/Body/m_case_.htm)

</comment><comment><USER14> For the longest time I've heard that "Lisp is awesome", but no reasons why and when I've asked why, the answer is usually, "you have to try it to see it"

This article is a pretty nice down to earth point by point explanation why list is so cool. My question is: is that it ? lambdas, data is code, dynamic programing.. I mean those features are cool, but could someone post some more clear examples of why lisp is awesome?

<comment><USER15> See the HN-famous books "Structure and Interpretation of Computer Programs," "Paradigms of Artificial Intelligence Programming," and "On Lisp."

The claim is that Lisp is a language at a higher level of abstraction. You will have to study hard to be able to appreciate that level, but it cannot be explained in another way.

Imagine explaining Calculus to a high school Physics student. You're likely to get back: "But I can find the acceleration of an object by using normal algebra and subtracting its position at two different times!" Calculus is hard, its benefits are not clearly better than approximation or high school algebra until you reach a level at which you brain thinks of Calculus as fundamental and sees the old equations as merely derived, less-powerful versions.

Why would you expect a mind-expanding language to be any easier to explain?

<comment><USER14> Dude... that is a _very_ good analogy! point well taken.

<comment><USER16> Also, it's worth noting that all three books implement a subset of Prolog (in Lisp). Prolog is another language which sounds really bizarre, but can be incredibly powerful. It's less general purpose than Lisp, though - essentially, it works by searching for answers that fulfill all criteria you specify, backtracking to (lazily) generate alternative answers as needed. It's conceptually really cool, and is great for prototyping certain kinds of problems. Some of the literature is also quite good, particularly _The Art of Prolog_ by Sterling & Shapiro.

</comment></comment></comment></comment><comment><USER17> Instead of cond, you can use a switch.. it makes it even more succinct. I don't know why this post is rated so high thought.. it's like a copy of the preface of any scheme book.

</comment><comment><USER18> That switch statement doesn't work. You can't compare pointers(?) and string literals like that.

</comment><comment><USER19> I'm not declaring the awesomeness or otherwise of Lisp but you're a shitty C coder :)</comment>


The future of monetizing a mobile web app - <AUTHOR> http://blog.appstorehq.com/post/619247540/the-future-of-monetizing-a-mobile-web-app

<comment><USER2> Isn't this post a blatant advertising for AppStoreHQ ?

It's not like i learned something new from it, they just promoted their future app store.

Sometimes i wish there was a down-vote on HN...

<comment><AUTHOR> I didn't actually mean for this to be a blatant advertising post at all. I'm really sorry you feel that way. Hopefully I can help explain my real goal better here:

My goal was to help educate developers to the fact that mobile web apps have a bright future. Developers don't necessarily need to feel trapped by the popular native mobile platforms (iPhone, Android, etc) when there are other options available that are more open, more familiar, and easier to port to many different devices.

Still, mobile web apps have a long way to go for both developers and users, and distribution and monetization are two of the most important vectors that need to be improved. The point of the post was to show the potential of mobile web apps first, and to show how AppStoreHQ is helping these vectors for developers and users second.

<comment><USER3> _I'm really sorry you feel that way._

That's not how you accept responsibility, that's how you shift the blame back to the aggrieved person and piss them off some more. I don't have any strong feelings in this situation, just pointing out a place where can save you plenty of problems down the road: apologize unreservedly or not at all. For a better take try this:

 _I'm sorry I came across like this, I meant better than that._

</comment></comment></comment><comment><USER4> Google announced a Chrome Web Store that does exactly that.

IMHO this is Apple's blind side, too. I can rebuild most of the appstore's apps in HTML 5 and "sell" them through mobile safari. Apple doesn't get a ut if I do that.

<comment><USER3> Have you tried? It seems to me that it's very hard to replicate the native feel of the apps in HTML as there is always some imperceptible lag that kills the experience compared to silky-smooth native cocoa touch. Nothing prevents Apple from maintaining or even widening this gap, if they chose to.

<comment><USER4> Here's some things that prevent Apple from having the AppStore compete with web-apps:

\- Developer Support: Web apps only need to be coded once for all platforms. Deployment is in only one location (instead of all installed devices). tTe idea of a thin client is VERY appealing to many developers.

\- Mobile Safari: If Apple wants their mobile browser to remain competitive with Google's mobile browsers they need to support the very features that will kill the AppStore

\- The AppStore policies: I can publish apps that would violate the AppStore's terms as a web-app. It will be cross-platform and can even be things like a code editor or a porn browser.

Go and try 280slides.com. We're very close already as far as UI and feel goes. IMHO it's very hard to deny the coming age of web apps and thin clients (aka the age of Chrome OS).

<comment><USER3> 280slides is terribly broken on the iPhone, so it proves nothing.</comment></comment></comment></comment>