Coca-Cola Disconnects Voice Mail at Headquarters - <AUTHOR> http://www.bloomberg.com/news/2014-12-22/coca-cola-disconnects-voice-mail-at-headquarters.html <comment><USER2> I'm a bit bemused by all of the voicemail hate on here. I'm 42, so I feel I'm in the area between those that hate phone calls (younger, in general) and those that hate texting (older, in general). I enjoy being reachable by people (family, clients, employees, etc.) and I don't want them to have an obstacle to sending me a message. Certainly voicemail is an annoyance but it's also often the best option. Just last night I was driving to the hospital to visit a friend and called another friend to let him know the status of my sick friend. I left a voicemail and it was the best solution.

I've noticed that the texting only generation seems to have anxiety about making or receiving phone calls and the real-time conversation that requires. I think some of the voicemail hate is just a reaction to that discomfort.

<comment><USER3> I'm 45. I prefer sms texts or emails to voicemail. I prefer sms texts or email to actuL voice calls too - it's just easier to share information. Of course sometimes phone calls are for just chatting and voicemails fail for that too.

Currently iMessages are causing considerable problems with silent fails and no option to send as SMS (which they used to have - not sure why that changed). All the other messaging solutions have some fairly big flaws too.

Also: i really really fucking hate the way I'll get a notification with a partial message, and then have to open the app to read the message. Opening the app to read the message has a delay of maybe a minute before the message downloads - why? Why can they show me a preview in a notification and then take an age to give me that same text in their app? This is particularly bad with Facebook's messenger app (so bad I'm tempted to delete the app and leave different contact details on FB) but als happens on Whatsapp and others.

<comment><USER4> The "send as SMS option is now hidden. If message you sent does not say "Delivered" under it, you can press and hold your message. There will be a "Sens as SMS" option in the context menu.

<comment><USER3> No, this does not work. I get [copy][more]. Selecting more just leads to a select & delete dialog, with no ability to send as SMS. This is to a contact where I had previously sent messages as SMS before.

</comment></comment></comment></comment><comment><USER5> In my office voicemail as just used as proof you tried to get a hold of someone. "They didn't answer my email, and when I called they didn't answer, so I left a voicemail". Once you leave a voicemail you have satisfactorily established to management that you have made every effort to reach someone. I haven't listened to a voicemail in over 3 years.

</comment><comment><USER6> The first thing I do when I sit down at a new job is disconnect my landline or VoIP phone and put it in a drawer. HipChat, Skype chat, Email, text, or FB message, please. Voice is dead to me.

I'm looking forward to the day when you can buy a SIM card from a cell carrier which offers only data and text, no voice call support.

Also, am I the only one that is mildly disappointed that Coke's headquarters isn't shaped like a huge Coke can?

<comment><USER7> > Also, am I the only one that is mildly disappointed that Coke's headquarters > isn't shaped like a huge Coke can?

This is absolutely ridiculous. Do you expect Subway's headquarters to be shaped like a cold-cut sandwich?

In all seriousness, The Coca-Cola Company produces and distributes only their syrup concentrate to franchisees, whom bottle it for sale. Yes they have a subsidiary which oversees North American production and distribution of beverages, however that is the only one they own and operate.

And, with that in mind, their headquarters should resemble a large bag of goo instead of their trademark bottles.

<comment><USER8> But they have a trademark on the bottle design.

<comment><USER9> But the person he was responding to wrote "coke can" not "coke bottle."

<comment><USER8> That's true, and I responded to a comment that even included the phrase "trademarked bottles." I simply wanted to point out that Coca Cola owns more than the formula.

That's not to suggest that I would want to work in a building shaped like a bottle, a can, a newspaper, toilet bowl cleaner, or anything other than a building.

</comment></comment></comment></comment></comment><comment><USER10> I lived in the US and currently in Brazil, so it's great to see two different aspects of the "voice mail culture".

Before cell phones were introduced here, almost every one in middle class had someone bring them an answering machine. When cell phones started showing up, thou, people didn't use voice mails that much.

Today, when you wanna talk to someone and they're not available, you just leave a text or a WhatsApp message. If it's not that important, they'll just see their missed calls and call you back.

This article made me remember that when I started working in the US, my boss got mad many times because I NEVER checked my voice mails so I missed meetings etc. Haha!

<comment><USER11> I believe part of it is that in Brazil, at least for cell phones, only the caller pays, not the receiver of the call as well (as is the case in the US). It's pretty common to leave a short message of the form "call me back", or just a missed call - a longer message wastes your minutes.

</comment></comment><comment><USER12> My voice mail message at work for the last few years has suggested that people contact me through email and that I tend to ignore my voicemail blinking light for weeks at a time. As a bonus (for me), I don't include my email address in the message so the only people who typically leave me messages are vendors cold-calling me.

<comment><USER13> I just moved my phone so I couldn't see the light when I'm sitting at my computer. In the past I've taped an index card over it

</comment></comment><comment><USER14> I think this makes a lot of sense for a business. Sadly, I still get occasional but important personal communication via phone calls and voicemail, where otherwise I would not be able to get it. Specifiaclly, doctor's offices don't use SMS or email. Their alternative is snail mail. Another source is random one offs such as the oil delivery guy confirming my delivery, or a relative trying to get directions to my house in realtime.

I get very few voicemails, but I don't see a point in disabling this feature entirely, in on personal line.

<comment><USER15> All of our doctors contact us through email. I think they use Epic, and we get all of our test results, appointment reminders, etc. there. With health care regulations forcing electronic records, we'll probably see more of this.

<comment><USER16> It's tricky with HIPAA, given that emailing almost anything interesting is a violation, since they can't control whether your email provider discloses it or not.

The right way to do it is to email people and inform them that a secure system has Very Important Information for them and that they should sign in using pre-arranged credentials to check it. Even _that_ email can be a HIPAA violation if you do it wrong -- for example, "Hiya Jane Smith, Dr. Foo OBGYN has important information for you" has been held to be a violation since Foo should have reasonably anticipated that some patients would be living with family and sharing email with them and disclosing a non-minor's pregnancy/etc to their parents without their consent is a per se violation.

Ditto putting similar information into voicemails / SMSes / etc. Technical violations of the rules are rampant and enforcement actions are comparatively rare, particularly at smaller medical providers.

<comment><USER17> Well that's one nuance - another against voicemail for Doctors is that if you truly have an emergency, then it's possible practitioners are liable if you suffer while leaving a voicemail (or as a result of no one listening to that voicemail in time).

Consequently, none of my doctors have a voicemail, so I'm forced to use their app to communicate with them, even if I just want a "you and/or kids are probably ok, come in if things get worse" confirmation.

Very few have an "answering service" that has a real person transcribe and page the doctor (and advise you call 911 if it sounds like an emergency) but I imagine this is too expensive for most.

</comment></comment></comment></comment><comment><USER18> It's interesting - but I've noticed that, without any discussion whatsoever, we stopped using Voicemail at my company somewhere in the last three years. I haven't listened to any voicemail whatsoever in about two years.

A lot of my customers in the UAE and Singapore Region have switched to one of calling directly, and expecting you will _always_ answer (Dubai), or alternatively making extensive use of Whatsapp/Whatsapp groups (Singapore).

Voicemail though? Completely dead.

</comment><comment><USER19> It's too bad. Voicemail to email (with attempted transcription) is awesome usability for the message sender and not bad for the receiver.

</comment><comment><USER20> Having to work with vendors a lot it would be difficult for me to give it up. I know, they could simply email me, but the reason for the voice mail was the immediacy of the situation. Likely if they leave one they will zip out an email, but those take more time to write than leaving a voice message.

Now I can see the reason for ditching voice mail if this is how some people are dodging responsibility. Seen that, where people will ignore calls and pretend to not be present. Instant messengers only work if they are mandatory, where I am you can simply leave it off so again your "not there". Many email programs can block return receipts.

So what problem are they really trying to solve?

<comment><USER21> The problem is that voicemail is obnoxious to use and pretty pointless. The last company I worked for, I didn't even have a phone number, let alone voicemail. If someone needed something they could use an asynchronous form of communication, like email or IM (we were required to use Hipchat).

The last job I had where I had voicemail I refused to check it. Not because I was dodging work, but because listening to long, rambling voicemails is time- consuming and irritating. I can skim through a rambling email very, very quickly to get the information I need. I can also search my old emails quickly and easily. Neither of those things is true for voicemail.

</comment></comment><comment><USER22> I have had a soft phone at my last two jobs, and it was never used. We used Skype or Slack for our text communication, and Google Hangouts for more personal communication. And it worked perfectly well for maintaining a good flow of communication.

Voice mail is, like texting, an asynchronous method of communication, but it requires more hardware and mental context switching to receive and respond to voice messages.

I think the biggest hurdle to adopting something like this is going to be the different perception of voice mail (and phone calls in general) between generations.

<comment><USER23> voice mail is asynchronous for the person sending it, but it's somewhat synchronous when you're on the receiving end: you cannot skip through the boring parts right to the interesting content, you have to linearly listen to the entire message. I think this is the biggest problem with voicemail. If all voicemail could turn speech into text, and it would end up in your e-mail inbox or "voice mail" app on your phone, we'd have the best of both worlds.

<comment><USER24> This is what I use Google Voice for. It translates the voice mail into text, and will send it in an email. It's not perfect, but it's good enough to figure out why the person called, and it does a good job capturing the phone number the person leaves.

<comment><USER23> damn, I'm not in the US but that sounds very cool. Is it US only? I'm sure that's why 97% of our generation dropped voice mail. It's just not as convenient as text.

</comment></comment></comment></comment><comment><USER25> Voice mail is too often used by windbags to hear themselves talk instead of getting to the point. In protest of those that seek to waste your time and mine on unnecessary formalities, I purposely don't leave nor listen to any voicemail. Period. It's just too slow and infringes on other people's time, like that step uncle everyone always dreads seeing at the holidays.

Instead, send a very short email with the content in the title and <EOM>. You're done.

(And no, Google Voice transcription isn't good enough.)

</comment><comment><USER26> So, does this mean that everyone's personal phone will now be inundated with SMS messages from work at all hours? Will all of their internal extensions now have an SMS endpoint to receive text messages?

I know so many people that will only text and not hold an actual voice conversation. It's really irritating to say the least. In general if it's a short "I'm running late, eta 20 min" or "heading to the store, let me know if you need anything" I'll text (the store list is even better that way, it's written down... But anything more than that and a one-two minute conversation is better.

I've been a rabbid google voice (formerly grand central) user for several years now.. I love the voicemail transcription. The only annoyance is I have to "press 1" to answer, and that's harder to do while driving... no idea why it isn't "press one, or say 'answer' to answer". Just the same, getting rid of it altogether is ridiculous. Having GV-like integration with their desktop and phone platforms would have been a better move all around.

My two issues come down to.. A) Keeping work time and personal time separated.. and B) From the outside how are you supposed to reach anyone?

</comment><comment><USER27> I think the main problem with voicemail is that, for the most part, it is disconnected from the Internet.

We run Asterisk, when I get a voicemail it is as an mp3 in my email. I know the caller ID, when it was left and how long it is before I choose to listen to it.

It is totally useful.

It has always boggled me that I can't choose "send audio message" from my smart phone's contacts without a third party app - a feature that I use on watsapp regularly.

</comment><comment><USER28> Since my company has a PBX I recently change the settings that all voice mails left on the phones are emailed to them, directly, that saves space in the phone server. I rarely listen to the VM I get, I prefer calling first, if no answer then I listen to them.

<comment><USER29> _I rarely listen to the VM I get, I prefer calling first..._

My goodness, that's annoying. b^) You're certainly not the only one. At least once a week I leave someone a several-minute voicemail with specific detailed information, questions, or instructions. Then ten minutes later they call back, "what did you want?" MFW...

Keep in mind, these are people whom I would gladly send an email, if they would read their email more than occasionally.

</comment></comment><comment><USER30> Voicemail is dead, and it's because of the significant minority that leave giant messages, as well as anybody you never met who "just wanted to touch base with you". It's a shame too, because there are times and topics for which texting/emailing is an incorrect alternative.

Unfortunately people don't realize the 3rd rule of Dr. Luther Waxling: "Just because it happened to you doesn't make it interesting" (at 1:24 [https://www.youtube.com/watch?v=NGfc2zZ2PQI](https://www.youtube.com/watch?v=NGfc2zZ2PQI))

<comment><USER31> The worst part of voicemail was not even the monologues, but the fact that the important bit of information may be hidden deep within the various boring screed.

The issue is that most people have no idea how to communicate and voicemail is a very painful method to be forced to endure from someone who cant get to the point.

Email generally takes more effort to produce (since its not as much of a train of "thought") and its way easier to summarize as the consumer, so you can just hunt out the golden info in the pile of crap.

</comment></comment><comment><USER32> At my internship this summer I actually had a sticky note on top of my phone to tell me what buttons to press in order to listen to my voicemail. It was like 3 different menus you had to go through, and then you had to listen to all the voicemail metadata (including the second that the voicemail was sent) just to listen to the 10 second voicemail of your boss telling you to call her back. If coke was anything like this place, they made a good decision.

<comment><USER26> Just because the interface is bad, doesn't mean the concept is bad... I've used Google Voice since it was Grand Central, love it... I never call in or press buttons... it's an app on my phone, and a website ui I can use... easy peasy.

</comment></comment><comment><USER33> Corporate voice mail is a nightmare with the press 7 and 9 systems. If it was like a modern smartphone (e.g. Visual Voicemail) then it would be ok. At this point, I am trying to figure out what to replace the college's current Nortel[1] system. I think the mp3 e-mail voice mail would probably make people a bit happier.

1) why yes, the words "current" and "Nortel" should never be associated, but that's where we are

</comment><comment><USER34> Any medium will create pseudo-communication. How many times did I get POed by endless email exchanges (particularly the "Thank you" kind). So the problem is pseudo-communication not the medium. I suspect that CC thing has more to do with time management than technology. The 100K/year mentioned probably refers to hardware and maintenance. Now if you factor in the wasted minutes you might get a different number.

<comment><USER26> I actually find email exchanges far worse than voicemails.... I use google voice, it's in one interface, and voicemails are few enough... 5-6 a day.

Emails, I see many... Some I bucket off and group delete daily.. others I have to spend half an hour a day to sift through... it's a pain. Especially reply chains... Though I'd just as soon use IRC, getting people to use slack hasn't been so bad (there are hipchat and others)... I'm not a huge fan of IM either though.

</comment></comment><comment><USER35> Things like this is what leads to billion dollar valuations for companies like Slack. Corporate communication is finally evolving from email and voicemail.

</comment><comment><USER36> Here's what I want to know: We have Cisco phones, and when I get a VM, the phone's message light comes on. I also get an email with the MP3. If I delete that email without opening it, the message light goes off on the phone within a few seconds. We use gmail for our company email.

How on earth do they do that???

<comment><USER37> With SOFTWARE. It's the latest thing.

</comment></comment><comment><USER38> Why wouldn't you want to give your customers every opportunity available to get in touch with you?

<comment><USER39> Do you have a fax machine and a telex?

</comment></comment><comment><USER40> In 2012 when I purchased my own phone I declined to set up a voice mail account. If you call and it rings out, the caller is informed, "This customer has not created a voice mail account."

I highly suggest you do the same. The only person who've noticed so far is my mother.

</comment><comment><USER37> I'm old enough that I've lived through these stages:

1) There were no answering machines and no cordless phones, much less mobile. If you called someone at home, and they didn't answer, you just tried later. If you called someone at a business, everyone had a secretary who could pick up if they didn't answer. She (and it was always "she") would write your message on a message slip (they were generally pink) and put it on the person's desk. Or, for smaller businesses, you called the main number, and the operator would connect you, and take a message if no answer.

2) Home answering machines happened. They used cassette tapes, and you could rewind and replay your messages. The outgoing greeting was on a second tape. When you got home, or if you were screening your calls, you'd see a blinking light indicating "new message", then hit buttons to rewind and play your messages. When the tape got full you could put in a new tape or write over the old messages. For businesses, phone systems became smarter and could take voicemail, but this was expensive, many businesses still used the old people- intensive way for messages, and many businesses preferred this because customers liked talking to a real person to leave a message.

3) Mobile phones with SMS became available to consumers. (We are into the 90s now). I don't recall this being especially popular at first, most people still left voicemails, even on mobile phones. But SMS became more and more used over the next decade plus (before smartphones when they exploded in popularity).

4) Fast forward to today. People born after 1980 or so, I find, really don't do voicemail at all, text messaging is the thing. If you leave them a voicemail, it doesn't get listened to. The best you can expect is a callback or a text message because they saw you called, but the usual response is nothing. For businesses, some form of instant messaging (IM) is prevalent inside the company. The IM might say "Hey do you have a minute to talk OTP?" but no one just calls someone else cold, much less leaves a voicemail and expects a response.

IMO stage (1) actually worked fine, and now that we are at stage (4) that works fine too (as long as you don't pretend voicemail is a thing and use other means of communication). The intermediate stages were awkward at best.

I think Coca-Cola's action makes a ton of sense for any company. Maybe it was fear of legal discovery that prompted it, maybe it was what they said (streamlining operations), but it is a good thing, IMO.

</comment><comment><USER41> Voicemail doesn't seem as "on the record" as email. I wonder, does this matter?

<comment><USER42> > Voicemail doesn't seem as "on the record" as email.

Funny, I had the opposite response. Since it was Coca Cola HQ that ditched VM, I was guessing they didn't want those records around. (Sarbanes-Oxley requires maintaining the VMs IIRC).

As many point out, there's more verbosity to a VM than email/text, and that can work against you in bad situations, like an investigation.

</comment></comment><comment><USER43> I recommend using Google Voice as your voicemail service, in that it converts voicemails to text messages. They're often garbled text messages, but it's enough context to decide how to respond.

<comment><USER44> It also makes dealing with voicemail a great deal better. I despise voicemail at my work because I have to call a number, listen to the message and clear it to make my phone stop blinking. On my cell phone it just pops up as a text message, I can read most of it to get the gist and clear the notification easily.

</comment></comment><comment><USER45> I used to work at a company that had an office phone system with desk phones and all. To this day I consider that kind of system a most confusing piece of technology I tried to use.

<comment><USER39> Not yet worked anywhere that doesnt... although I almost never use said phones.

</comment></comment><comment><USER46> Is voice mail recording device at home still popular in US? Often seen in US movies but such device has never caught on in Singapore/Malaysia.

<comment><USER47> I suspect they're increasingly rare. Even for those who want voicemail, it's increasingly bundled as part of voice plans rather than requiring a dedicated voicemail device at the receiving end.

</comment></comment><comment><USER48> Next, do email!</comment>


Australian Dating Industry is on the Verge of Big Bang - <AUTHOR> http://www.isisandosiris.com.au/ Australian dating industry is on the verge of the boom because it is making way for the new and improved sites.... that are making the online dating a pleasurable and precise experience for the singles.. <comment><USER2> if you prepare a splash page to entice people to your offering, its a good idea to make it readable.

your egyptian background is artistic but makes it awfully painful to read the text

<comment><AUTHOR> Hey pal, the real site is going to up on 6th of August... I am sure you will love the site when once it will be up.... :) thanks for your suggestion though..

</comment></comment><comment><AUTHOR> this is true what is happening here....</comment>


Girl lives on train instead of in an apartment - <AUTHOR> https://www.rt.com/news/313171-german-girl-lives-train/

<comment><USER2> A more appropriate title would be "Girl lives with boyfriend but commutes via train to School"</comment>


Google made large contributions to climate change deniers - <AUTHOR> https://www.theguardian.com/environment/2019/oct/11/google-contributions-climate-change-deniers <comment><USER2> This thread of thought was way more interesting than I assumed from the title: the issue is that some of the same groups that defend Section 230 happen to also be climate change deniers, and so it becomes this question of the morality of single issue politics (which affects normal people as well making decisions at the poll).

<comment><USER3> I don't think it's controversial. Don't support groups unless you know what they're doing (and you support that).

Google either didn't know or didn't care. Neither are acceptable.

<comment><USER4> > Google has defended its contributions, saying that its "collaboration" with > organisations such as CEI "does not mean we endorse the organisations' > entire agenda".

So, in your opinion, you should never engage with anybody that you disagree with on any issue? It would seem that you wouldn't have many people left to interact with.

<comment><USER3> _Engage with_ and _Shovel money into_ are subtlety different, aren't they?

We are talking about lobbying groups and a company with operating profits to rival some GDPs. If Google wanted to support a cause, it can do that without also subsidising climate change deniers.

</comment></comment></comment></comment><comment><USER5> Why is every group calling the benefits of climate change legislation into question immediately smeared as "climate change deniers?" It's perfectly valid to look at the science, accept its conclusions, and remain unconvinced by the economics in cost-benefit terms.

<comment><USER6> Imagine that a meteor is heading toward the Earth, and there's a 50% chance that it will hit us and wipe out all life, but we won't know whether it will for sure until later and if we want to be able to stop the meteor in the case where it will we need to start preparing now at immense cost.

In this scenario, if you say "we're not 100% sure it's going to hit the Earth so we shouldn't prepare until we know for certain" does that make you "unconvinced"? Or does it make you a "denier"?

<comment><USER7> So are you actually concerned about CO2 driven climate change or asteroid strikes? What about all the other things that could potentially eliminate civilization?

Something something Pascal's wager...

People constantly talk about "externalities", which implicitly means the downside of using fossil fuels isn't infinite. Equivocating between "infinite" and "actually a rather small amount on a global scale" makes anyone paying attention tune out. You've got to consistently fake sincerity to influence people. Or I used to think so.

</comment></comment></comment><comment><USER8> Maybe I'm too cynical, but I wonder why people are so surprised that Google would prioritise Internet deregulation higher than climate protection? More Internet regulation would directly impact Google's shareholders, climate change not (or not in the immediate future). So... Ok, there was this "don't be evil" thing, but it's been a looong time since anyone at Google has mentioned that...

</comment><comment><USER9> While I am not familiar with any of the organisations mentioned in the article, I think it is a good thing when non-mainstream views are financially supported. The headline is "large contributions", but later it is specified as "more than a dozen organisations" out of "hundreds of groups". So it's not like it's a focus of Google's spending.

Being able to support opposing viewpoints, and allow them to be funded and researched, is what (should) differentiate the West from China, where opposing viewpoints are deemed dangerous and must be shut down.

<comment><AUTHOR> So in this case, by non-mainstream views you mean lobbying based on made-up research and plain lies I assume (it is what climate change denial lobbies use most of the time)

<comment><USER9> I can't know what research is 'made-up' and what isn't. I just know that it's not helpful as an argument to always claim that the other side it lying.

<comment><AUTHOR> There is no other side in this case in my humble opinion. What we have is overwhelming scientific evidence supporting climate change, and some made-up research paid by carbon industry lobbies, like some of the organizations funded by google mentioned in the article, which deny climate change.

<comment><USER9> Does any of them literally _deny_ climate change?

I did a quick Wikipedia check on first two of the mentioned organizations, CEI and the Heartland Institute. Both seem to acknowledge that the climate changes because of human action. They are called 'climate deniers' because the other side does not agree with them on policies.

<comment><AUTHOR> I haven't been precise enough, sorry. They deny that drastic carbon reductions are needed as a result of climate change. In other words, they deny that climate change is the cause of carbon emissions, which to me is denying climate change.

[https://www.heartland.org/publications- resources/publication...](https://www.heartland.org/publications- resources/publications/climate-change-reconsidered-ii-fossil-fuels---summary- for-policymakers)

In this new volume, 117 scientists, economists, and other experts address and refute IPCC's claim that the impacts of climate change on human well-being and the natural environment justify dramatic reductions in the use of fossil fuels

<comment><USER9> I agree that this paper, at least the 'summary for policymakers', is trash and comes pretty close to denying. It scratches on the surface of some good points, but doesn't follow through. But even then, I rather have someone offer a (stupid) counter-argument than no counter-argument at all.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> CEI? AEI? Heritage Action? Google supports _those_? Those are the classic conservative PACs.

Although, in the era of Trump, they're starting to look not so bad.

<comment><USER11> Google have _long_ supported those and others, which I'd called out back on G+. Much of the major Libertarian / Koch octopus / Atlas Network / Mont Pelerin front groups.

Exceedingly disappointing. Glad to see it getting called out.</comment></comment>


This guy pushes startups out of a coffee shop - and hes 11/11. - <AUTHOR> http://www.businessinsider.com/not-y-combinator-io-is-like-a-family-2012-1 A nice story about @bragiel and his seed fund @io ventures and the work they have been doing over the past 1.5 years. <comment><USER2> Interesting to note: the coffee shop in question is The Summit, which is closing down (and/or moving to a new location that hasn't been found yet).</comment>


Microsoft provided first look at Visual Studio 2010 and the .NET Framework 4.0 - <AUTHOR> http://bink.nu/news/microsoft-provided-first-look-at-visual-studio-2010-and-the-net-framework-4-0.aspx

<comment><USER2> Are there any specifics? The article only mentions fuzzy market-speak buzzwords.

<comment><AUTHOR> should you expect any more?</comment></comment>


Dagny: Rails-style Resource-Oriented Architecture for Django - <AUTHOR> http://github.com/zacharyvoase/dagny

<comment><USER2> Comparisons to django-piston and motivation for creating this library would be helpful.

<comment><AUTHOR> FYI: I'm working on a pretty full suite of documentation at the moment, since the README has become a bit overloaded.

The motivation for creating this library was pretty simple: I really like the Rails way of modeling the application around resources, and then 'mounting' those resources at URLs with the absolute minimum necessary amount of code. This resource-oriented approach is key in building truly 'RESTful' web services.

I wanted a simple but powerful content negotiation mechanism, which effectively gave me a comprehensive 'API' with zero additional effort. I think I've achieved that here; for example, adding JSON output support to a specific action is usually a 3-line affair, or you could very easily write a generic renderer and enable it for _all_ actions across your entire site.

Finally, even though the Rails inspiration was so strong, I needed to keep Dagny as consistent as possible with the practices and idioms of the Python and Django communities. Again, I think I've done pretty well in that regard.

In response to your other question, I think Piston is a great library—however, I think the idea that you have to define an API _separately_ from the rest of your site is just the wrong way to do things. I'm also not a big fan of Piston's architecture and resulting API; it's not as polished as I'd like it to be (although that's more of a cosmetic issue).

<comment><USER3> Did you check out Tastypie (<http://toastdriven.github.com/django-tastypie/>)? It is also RESTful, and explores some similar ideas as a replacement for Piston, but approaches it in a manner similar to Django models.

<comment><AUTHOR> It's quite a nice solution actually, but I'm afraid it's far too coupled with the Django models for many of my use cases. A lot of the time you'll create a Resource without any model to back it—for example, most Rails projects use a UserSession resource for logging in/out, with logging in => new/create, and logging out => edit/destroy.

</comment></comment></comment></comment><comment><AUTHOR> Dagny now has some proper HTML reference documentation: <http://zacharyvoase.github.com/dagny/>

The tutorial is very much a WIP though.</comment>


Ask HN: PHP vs. Node.js vs. Go for a new startup? - <AUTHOR> I am coming back to the IT industry after about 6 years of being involved in something completely unrelated. My partner and I are starting a startup that's going to make a online blogging application for a niche market. If we are successful, the application would need to be able to scale to handle a lot of users (100k visitor per day if we are successful, nothing like FB levels or something). Because it's going to be a blogging platform with a business model similar to squarespace.com, the load will be distributed over many different domains, making it easier to scale.
Both my partner and I have good knowledge of PHP. However, due to the complexity of the project, we will have to find additional developers anyway. From what I read online Node.js and Go are the in thing right now, and scale much better than PHP. My question is, should we stick with the "Devil we know," PHP, or dive into learning and developing in Node.js or Go. Should we consider another programing language / platform?
What are your thoughts. This are honest questions, we are just looking for some feedback. Thank you for your help. <comment><USER3> Unless you know you _can 't_ use what you know, stick with what you know. Business concerns trump technical concerns for early-stage startups, and the differences between the three are minute as far as business is concerned. However, having to struggle with learning a new stack _can_ impact your business.

Even if the differences between node.js and Go mattered, you won't get anything valuable from asking HN "should I use node.js or Go", since the two stacks are broadly in a similar niche and have similarly-sized communities. It'll mostly be fans of one technology bashing the other, as you can already see in this thread. It would be better to focus on specific concerns: Do you need support for shared memory on multicore? Is the ability to reuse JavaScript code on the browser and the server a concern? Is there a specific library that's essential to your business that's only available on one or the other? These questions would engender a much more interesting discussion.

<comment><USER4> node's error handling is by far its weakest point IMO, Go is a lot better in that respect, but a full javascript stack has its advantages

<comment><USER5> I remember you criticized on twitter this point of Node some time ago and the response of some leaders of Node community was like "Sorry, this isn't Erlang" and "Erlang is better but it's harder"

<comment><USER4> Yeah, pretty naive responses, but understandably most people who have been in the community for a long time don't want to admit the reality, seeing as node is what powers most of our jobs haha. Bottom line is node has a massive flaw, and it should be fixed, at least core members should have interest in fixing it.

Especially with tools like Go there's a lot of pressure to NOT use node in production when great alternatives are available. Node still has the "JavaScript edge", but if fault tolerance remains as poor as it is now that won't matter for long.

</comment></comment></comment></comment><comment><USER6> Write it in PHP to start. If it takes off, hire a bunch of devs and rewrite it in Go. I say this as someone who hates PHP and generally likes Go and Javascript.

The biggest question in your business model is not "How do I scale this?" or even "What technology should I use?", but "Will this take off?" If the answer to that is yes, you will have resources to deal with the problems of how to scale it, and you will have more information to answer the question of what technology to use. (In particular, you'll know what your developers want to use; you can give them an ownership stake in the technology decision - <USER2> should really be _their_ decision, not yours; you will know exactly what feature set you need to implement and what sort of loads you'll bear; and additional libraries or technologies may have come out in the meantime.)

Usually the biggest factor in development time is how well you know the technologies you're using, not any intrinsic level of productivity with the tools. Different technologies will top out at different levels, and IMHO Go tops out significantly higher than Node.js, which tops out significantly higher than PHP (and at least in the early stages, Python tops out higher than Go). But if your goal is to found a successful company and you know what idea you want to pursue, you are better off investing the time in proving out your business idea than in learning the perfect new technology. (If you don't have a concrete idea, investing in learning a new technology is a pretty good way to pass the time until you do.)

<comment><USER7> Exactly, and I'm in the same situation and we decided to go with PHP (as much as I loathe it) because any cheap hosting has PHP enabled in their base offerings. If things kickup and our idea is validated and we can hire some devs, then we will use something else.

</comment></comment><comment><USER8> If I was starting from scratch today I'd use Go. Go makes writing fast, scalable and reliable servers as easy as it is possible to make it. At least that is my experience.

I started out writing CGIs and servers in C many years ago and have experimented with Perl, Python, PHP, Ruby, NodeJS and Go since then.

Go has a syntax that is instantly familiar and simple to master. Go's concurrency paradigms are simple to understand and easy to use. Go's compiler is fast and clear. If a Go program compiles it nearly always runs. Go's built- in library has most things you need to write HTTP-based servers.

If you use Go naively you will almost certainly be using Go correctly: your server will be fast and efficient. This is not the case with NodeJS. Writing fast, efficient NodeJS code is hard. Maintaining fast, efficient NodeJS code is even harder.

On the down side - while Go don't suffer from 'callback hell' but it does have a tendency towards 'cast soup' \- this makes working with JSON a little trickier than it should.

Aside from the main programming language I would also look at:

* JSON API-first driven development

* Redis

* NodeJS's plethora of web-centric code management tools & compilers: SCSS, RequireJS, Grunt etc

* Single-page javascript App technology: Ember, Angular etc

* Docker.io

* SVG

* Camlistore

These (with Go) are the main technologies I'd use to build a large web infrastructure.

<comment><USER9> Node doesn't suffer from callback hell if you're an adequate javascript developer. Named functions?

Or how about a class which you pass methods to your callback functions and bind them to the instance properly.

You never need to nest a callback if you know how to work with prototypical inheritance.

<comment><USER8> So, clearly, I'm not 'an adequate javascript developer'.

Luckily an inadequate javascript developer can write naive code in Go that reads from disk or writes to a socket without worrying about needing "a class which you pass methods to your callback functions and bind them to the instance properly" or "prototypical inheritance".

You can just call a function and use the result.

</comment></comment></comment><comment><USER10> Stick with what you know so you can get your start-up off the ground quickly and cheap. Once you hit PHPs limits, you can still gradually migrate over to $whatever_language_is_hipster_language. Regarding node.js and Go explicitly, I'd give those two at least one year of "maturing time" until you use it for mission-critical stuff.

</comment><comment><USER11> Pick what you know the best. You will waste time in learning something new instead of working on your product.

When time comes, you can always optimize it(writing performance critical parts in c), or pay guys who are better than you to "translate" your app to another language.

God knows i'm not following this advice, but please do not fall into a "premature optimization" trap.

</comment><comment><USER12> PHP.

You want to start with something you know, especially at a time when getting an MVP, making iterations, and being nimble is important. Because you both already know PHP, this is a no-brainer. Things have changed dramatically with every aspect of web development in the past 6 years, and PHP is the thing that (although its changed a lot) has probably changed the least compared to your web front-end (HTML5/CSS3), client-side JS, and responsive design (which basically didn't exist 6 years ago).

You should also consider the economics of your situation. Developers who know enough about Go and Node.js to do it professionally are going to charge you much more than those who code PHP professionally.

Ultimately, you're probably doomed to failure just by raising this question. Its been stated ad nauseam on HN before, but you need to iterate quickly and discover what works and drives traffic/sales. Don't waste time trying to learn a new programming language. If you want to devote any time to learning something new, it should be learning how to market your product better.

</comment><comment><USER13> If it's performance you care about, here's a ridiculously exhaustive set of benchmarks for every web framework you've heard of, and many more you haven't.

[http://www.techempower.com/benchmarks/#section=data-r7&hw=ec...](http://www.techempower.com/benchmarks/#section=data-r7&hw=ec2&test=query)

I've got no love for PHP, but if you must, use a recent version and a decent framework.

<comment><USER14> That link filters it to the frameworks tested on EC2/Amazon, not showing Go and such. Main (i7) tests:

[http://www.techempower.com/benchmarks/#section=data-r7](http://www.techempower.com/benchmarks/#section=data-r7)

<comment><USER13> I thought the EC2 tests might be more relevant to an early-stage startup, although I had not noticed that some tests were left out.

</comment></comment></comment><comment><USER15> If you are starting a business and plan to be the initial developers, use what you know (PHP) because you probably won't have time to learn new stuff and build your business. I'd base the decision on who is doing the coding and what skills they have. Try to stick to standard frameworks and programming practices/decent docs, task/project management, and source control, making it easier to transfer responsibility and project historical artifacts to other developers or grow the team as you grow your business.

</comment><comment><USER16> 100k visitors per day is 4k visitors/hour is 1.2 visitors/s. Suppose each visitor clicks on 10 pages (that is very high) and you get a total of 12 requests/s. Now even assuming much higher load during peak hours you're still looking at max 100 requests/s.

My point is that that kind of traffic is truly minuscule. As long as you set it up correctly and use a decent cache it will handle the load fine. Any platform you choose and hosting for ~$200/month will be enough.

<comment><USER17> You're assuming that all the visits are evenly distributed over the day. I doubt that assumption will hold...

<comment><USER16> No, I explicitly assumed peak loads about 10 times the average, 100 reqs/s instead of 12 reqs/s..

</comment></comment></comment><comment><USER18> You know PHP, so use PHP. There's going to be a mountain of business challenges between 0 and 100K daily visitors - free up your mental bandwidth for that.

Also, something as read-heavy as a blog is well suited for something like Varnish ([https://www.varnish-cache.org/](https://www.varnish-cache.org/)). Regardless of the backend technology you choose, a caching http proxy (or whatever) should be absorbing most of the traffic.

</comment><comment><USER19> Go is a better language than PHP. Much better. It also compiles to machine code, and has excellent multi-thread facilities (goroutines) that boost performance and also make coding simpler (Not more complex!).

But you might find coming up to date on PHP easier, since you already know an old version of it.

There are many more coders available for PHP than Go. But Go programmers on average are higher in quality because the drudges and blubs don't bother learning new languages.

Recently one of my hosting providers sent me a notice that my account was being transitioned to a new version of PHP. That can't happen with a compiled language like Go, since the none of the language itself goes up on the website, only the executable program binary.

I don't know much about Node.js...

</comment><comment><AUTHOR> I am the OP. Thank you for the great feedback! I think this clarified our choices. I think we will go with PHP, simply because we know PHP now, and don't have to learn something new, as so many of you pointed out. I'll have to update my skills, but that's easy by comparison. I will try to design the project to be as modular as possible, to allow for easy technology substitution in the future. Some one also very correctly pointed out that our blogging platform will be read heavy, which allows for significant caching optimization.

</comment><comment><USER20> Learn Go! It will take some effort but it's worth it.

I am currently switching to Go from PHP. It's really not that hard to learn once you get your head around the static types and lack of OO - last thing is a big plus in my book. The way they handle it with structs and interfaces are so much better.

Biggest problem is there are limited ressources on the net about Go, and the documentation is lacking compared to PHP, examples are sparse. So be warned it will take you some time to learn.

But it's such a beautiful and simple language, that will be a breeze to support in the future for you and your team. Debugging and maintainability is top knotch.

And much faster than PHP. Node.js is also fast, but well it's not as maintainable, javascript is a pretty messy language. My thoughts on the matter is described well here:

[http://umugenzi.wordpress.com/2013/09/06/node-js-vs- go/](http://umugenzi.wordpress.com/2013/09/06/node-js-vs-go/)

For the frontend i recommend AngularJS

<comment><USER21> I have been using the same. I ported an entire ROR application to GO and Angularjs.

</comment></comment><comment><USER22> Building a startup is hard enough. Adding another rather large dimension of an unknown language/technology is increasing risks significantly. Untested/unfamiliar technology is one of the top 5 risks which cause software budget and time overruns (pick any book by Steve McConnel on software project management, he does a good summary of these risks).

If you think you have the time and resources, and more importantly, if an interesting technology is part of the reason why you wanted to do a startup; then take the numerous technical advice given by others here.

</comment><comment><USER23> If you count on 100k visitors per day, it doesn't really matter which one you choose. We are serving well over 10M page views daily and we don't see a reason to switch away from PHP yet.

The only reason I see you might want to go with Node or Go is if you want to attract developers who like to work with latest technologies. If you want to do the first version yourself, then choose the one you are most comfortable with. When you need to scale (from technical and resource perspective), make sure to analyse all aspects of it before going into one direction.

</comment><comment><USER24> PHP will take your 100k/day and work wonderfully.

PHP can easily take 1m/day.

<comment><USER25> PHP is rarely going to be a bottleneck, especially with opcode caching. Content heavy stuff beats up a database, so caching there, then stick Varnish in front of apache.

</comment></comment><comment><USER26> Depends on what you want to do. But I can tell you that this is sort of a pointless argument for a blogging platform

I've found that the really important bit when writing read-heavy web-apps is good caching. The write-path could be written in something slow-ish and it will be hit far less than the front-caches serving data.

So, if you need a web templating language + basic json callbacks, php will definitely do the trick for version 1.0 (or ruby-on-rails or whatever gets you up to 100% feature complete). I've written game backends which did ~2.5k-3k rps on a single machine with PHP (though, I did have to fix PHP APC's locks to handle those loads in the process).

But then you still need to know JS to write the frontend code.

Node.js basically lets you combine 2 skill sets into one - the frontend and backend can share the same data model code for instance. This is easy if you have complex data-structures to communicate between the two layers.

Go actually gives up that advantage, but wins out because it can do compute intensive tasks faster - and can do state-ful daemons in a much nicer way. If you were building say, an online game, where say it was poker game with low- latencies, I would go for go. Definitely.

But as it stands, the only reason to go for Node.js is that your front-end dev can double as a backend-dev. Otherwise, I'd stick with what you know & are most productive in.

</comment><comment><USER27> I'm going to go against the grain here and say ditch php and build it on node. There is no better way to update your skillset than by building your own product with a tool you've never used. If you're building a web app, you'll need to learn JavaScript regardless.

Worry about scaling problems when you hit them, not when you're picking a language. For comparison, I serve 100k users per day using rails/Postgres on a single $80/month linode server.

<comment><USER28> Building his/her business is more important at this point than upgrading his/her technical skillset.

<comment><USER27> "There's no time to sharpen the saw - I'm too busy cutting down the tree"

[http://www.codinghorror.com/blog/2009/03/sharpening-the- saw....](http://www.codinghorror.com/blog/2009/03/sharpening-the-saw.html)

</comment></comment></comment><comment><USER9> Node. Node node node node node.

Why node?

Node is a great framework for building web applications. It's got good support for scalable servers using Amazon Opsworks, nodejitsu, heroku, etc.

Javascript developers are easy to find, and even with no Node experience, any developer worth their salt can get up to speed pretty quickly.

Front-end and back-end can be written in the same language.

You can build rapidly and get to an MVP very quickly, at which point you can either switch to an enterprise language like Java (ugh) or Go, or whatever else to leverage performance, or scale your existing Node codebase using modules such as cluster, or by developing simple strategies on multiple servers.

I have built every kind of applicaton you can think of using Node, from desktop apps using node-webkit, to simple TCP video streaming servers using the built in networking and piping data directly into ffmpeg.

Testing and test driven development is natural in node, and you can write your server tests and browser tests in the same framework using mocha and phantomjs. I've even been building integration tests and automated UI tests using node, mocha and pahntomjs.

Our latest concurrent benchmarks for a load balanced group of t1 micros on a single mongodb instance get to at least 30k concurrent requests a second before you get a few timeouts, but that's just because i'm not too familiar with ops and haven't done any proper optimisation yet.

There is no right answer to this quest, but the above is my personal and professional opinion.

<comment><USER29> Summary:

A Javascript developer that have been using it for client-side purpose will not learn how to use nodejs from the day to night even if he is a expert on it, for something nodejs is for serverside programing.

"Front-end and back-end can be written in the same language.". I would prefer to right my backend in something else instead Javscript , even PHP would be a more pleasant choice, and if that would be the case i would rather use Clojure and Clojurescript togather to right everything in the same language.

</comment></comment><comment><USER30> Use whatever is best for you... PHP can scale... I've built applications that handled 4x as much visitors per day as you mentioned without any real problems... Crappy code is in every language, it's all on you... You can build amazing things in PHP... Just like you can in Node.js and Ruby, and Python...

If you want to build it quickly, do it in what you know best... If you want to learn a new language as you go, build it in Node.js or Go.

</comment><comment><USER31> If one were to analyze this concretely instead of with a bunch of platitudes, you want to find the optimal intersection between the productivity a language grants you for the task you are trying to accomplish, the amount of developer time required to maintain it, and the hardware required to support it.

1) Productivity - The speed at which you can create a respectable prototype. This is not just a matter of your team having mastered the language -- some languages are more specialized than others. For example, it will be orders of a magnitude easier (i.e. will require less dev time) to build a distributed system in a language with built-in actor support (i.e. Go, Scala, Erlang, etc.) than it would be to do so in say, PHP.

2) Maintainability (in terms of dev time) - The languages and its predominant frameworks will dictate how difficult it is to maintain a codebase. For example, many programmers will attest that statically typed codebases are easier to grok and maintain than dynamically typed. Dynamically typed code requires more edge case testing, and statically typed code allows an entire class of bugs to be compiled at runtime.

3) Hardware - Languages have different performance characteristics. Some languages will require $x / unit of web traffic. Others will require $y / unit. This translates into the # of servers required to support your app, which may diverge at a polynomial rate or worse over time. This is unlikely to be a big factor in the early goings, but it can matter a lot when / if you achieve success, so can be a worthy tiebreaker -- because it is highly unlikely you will be switching languages entirely once your company is in the groove, so the choice you make early on will stay with your company for a lifetime.

</comment><comment><USER32> Yes, use what you know the best. Might want to consider using a framework like Laravel 4 or Symfony 2 to boost your productivity.

</comment><comment><USER33> Great question. Other folks have made good points about the value of sticking with what you know but on the other hand there are advantages of other platforms as well. Could the kind of blogging application you've got in mind be built around Ghost? [1] If so then node could make a lot of sense.

I weighed a similar choice this summer and my first thought was Go but a friend suggested I look at node.js, Closure or Scala as alternatives. I wound up choosing node.js for an initial version because of the vibrant ecosystem with some great building blocks, mostly MIT-licensed.

jon

[1] [https://github.com/TryGhost/Ghost](https://github.com/TryGhost/Ghost)

</comment><comment><USER34> I am a big fan of Go, but why not python or even ruby? Seems either python/ruby would be a better fit for this kind of project than node/php, and easier to hire for than Go (since that was kind of alluded to as a requirement).

</comment><comment><USER35> 100K req/day translates to about 1 req/sec, which you can run on anything using any technology with zero scalability problems. it can probably run on my old TI calculator ;)

even if traffic has high peaks, scalability is not your concern.

Time to market and quality of people is. If you _are_ going to do it mostly by yourself with _some_ help later in the game, then do it in PHP. If you are going to hire people anyway, you might get a better talent by choosing something else. A blogging platform doesn't need a node/go level of concurrency. so don't discard rails and djungo.

</comment><comment><USER36> What's wrong with Python? I've messed with all 3 you listed but at the end of the day I always end up going with Python.

</comment><comment><USER37> i used go,php and nodejs.

let's say you want to create a bloging plateform like Wordpress. Wordpress code is horrible,but Wordpress has loads of features (and plugins).

1/PHP \- horrible language with very good libraries. Just look at the Symfony library, there is everything one's need to build a blogging plateform the sane way. And if you want to distribute your project as open source, you'll find more user with PHP that any other language.

2/ NODE Node is here to write servers. NodeJS is new,so dont expect libs to be as mature as php ones.

3/ GO i think go can be compared to nodejs but better. The way go deals with concurrency is better, the language itself it better than javascript. But same problem , new stuff, a lot of code needs to be written.

PHP has an interesting thing coming,Zephir that will allow you to write php native C extensions with a language close to PHP/Java but statically typed. so you could distribute your blog engine as a native extension.

</comment><comment><USER38> Here's an interview with the founders of StatusPage.io and about how they built it. You might find it interesting. In the end they stuck with what they knew - Rails.

[http://blog.leanstack.io/how-statuspage-io-was- built/](http://blog.leanstack.io/how-statuspage-io-was-built/)

</comment><comment><USER39> I'd strongly recommend using what you know best. If you're good at PHP, use that.

If, however, it's been a long 6 years and you're going to be pretty rusty at whatever you use, I'd recommend giving Node.js a shot. We've had really good luck with it and it has a fantastic community behind it.

</comment><comment><USER40> PHP is such a poor technology, however many great websites were build using it, so I would say that you should go with technology you know best.

PHP will rather never be a bottleneck itself, you can fuck up many other things like data storage. All modern data storage solutions come with PHP interface.

</comment><comment><USER41> Go with PHP and buy Steve Corona's book - [https://www.scalingphpbook.com/](https://www.scalingphpbook.com/).

Also, be sure to get up on the improvements that have been made with PHP 5, 5.3-5.4. It's come a long way in 6 years.

Good luck!

</comment><comment><USER42> If you are hiring "additional" developers then you need to go with something you know, unless you want to learn something new and get started on it first. Otherwise you are just hiring developers and not participating...

</comment><comment><USER43> PHP, given that's what you know. Also PHP developers are easier to find and cheaper.

As for scale, It doesn't really matter which you choose, because if you reach scale, the difficult bottlenecks will all be around the database anyway.

</comment><comment><USER44> If it must be one of those 3 options, I'd probably go with TypeScript running in Node.

Scala is another option you might want to look into.

For scaling, see: [http://12factor.net/](http://12factor.net/)

</comment><comment><USER45> If you don't care about performance issues, go for PHP, with a nice framework, so you can get ready quickly. Else, go for node.js (I don't know Go, but it seems it has a pretty good performance too).

</comment><comment><USER46> Bootstrap it on top of an existing CMS, such as WordPress or Drupal. It'll save you heaps of time. Hell, you may even be able to do it alone, with all the time you'll be saving.

</comment><comment><USER47> In brief: \- PHP => cheap developers \- Node.js => share code between client / server / meteor.js \- Go => multithread & performance

</comment><comment><USER48> It depend on what kind of online service you want create.

I think you will get 100 postings where 100 people try to convince you from their favorite language.

</comment><comment><USER49> Go with PHP.

It will speed you up. Scalability isn't an issue right now for you, so don't optimize for it.

</comment><comment><USER50> We have a server that we've deployed for our customers. It's a middleware-free web platform. It won't be released officially for some time but we'd be happy to have you evaluate it.

</comment><comment><USER51> How about Go vs Java/Scala/Clojure?

</comment><comment><USER21> GO for it. Go is much better and easier.

</comment><comment><USER52> Java.

</comment><comment><USER29> Summary: Php is a stable and reliable.

Nodejs: Is new and young.

Go: Same history as the one above.

Scalabilty is not something that you should worry about at this stage, if your app reach the scale that you expect it to get then refactor and do something about it. Scalability has nothing to do with the language, so use that "Devil you know", stop wasting time and move on.

</comment><comment><USER53> I'd go with a simple Rails or Sinatra app.</comment>


Programming languages ranked by expressiveness - <AUTHOR> http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/ <comment><USER2> Yeah, most of this is just drawing conclusions from what is essentially noise. Especially the consistency measure: that's bound to be heavily affected by how many people use a given language. The so-called "tier 1" are not popular because they're consistent--they're consistent because they're popular. The same goes for the tier 3 languages in reverse: they probably have so little activity that a high variance is inevitable.

Also, number of lines per commit is not really a good measure of expressivity. I don't even see how it's a reasonable proxy: the number of lines I commit changes more depending on my project (is it simple or complex, for work or for fun?) than on my language.

Also, it makes literally no sense at all to consider very domain-specific languages like puppet: you may as well talk about how expressive HTML or CSS are relative to normal programming languages!

Basically, I think this article draws too many arbitrary conclusions on limited data.

<comment><USER3> "the number of lines I commit changes more depending on my project (is it simple or complex, for work or for fun?) than on my language."

This amounts to saying: Some days I eat eggs for breakfast, but other days I eat oatmeal for breakfast, so I am totally inconsistent in what I eat from day to day, therefore it would make no sense to include me on a survey about what people in my country eat.

You do understand that a single data point might be useless, but when combined with thousands or millions of other data points, it becomes useful? What you do on any one project does not matter, but what you do, combined with thousands of other developers, all averaged together, starts to get interesting.

If you honestly believed your own premise, then you would expect all the results to be the same -- there would be no variation between Fortran, Java, Javascript, Clojure or Coffeescript, cause, you know, everybody is different and does different stuff, and its all so crazy, how can anybody make sense of it?

But we can make sense of it. All that is needed is a good understanding of probability and a sufficiently large data set.

Mind you, the article above might be total bunk. There might be lots wrong with the dataset. But its not bunk for the reason you give: " the number of lines I commit changes more depending on my project (is it simple or complex, for work or for fun?) than on my language."

<comment><USER4> With lots of data there's no doubt that they are measuring _something_ , but it's not clear that they are measuring what they want.

Your breakfast analogy would be more like:

\- Some days Alice eats crumpets while sitting in her house and it takes her about 20 minutes.

\- Some days Bob eats a bagel while on the way to work and it takes him about 5 minutes.

\- Therefore, bagels are 4 times faster to eat than crumpets.

See the problem is we have conflated lots of correlations at once. There is 1) a tendency for certain types of foods (languages) to be used for certain purposes, and a tendency for certain kinds of people to prefer certain foods (languages), and neither of those correlations are necessarily caused by the properties of the food (language) itself.

</comment></comment></comment><comment><USER5> I'm not certain that commit size is a good measure of expressiveness. Even not counting obvious outliers like javascript (oops, 3241245 people had a commit with jquery inside), it will be very dependent on the cultures in the different languages.

Some languages have users that are less mature in VCS usage than others, some languages have users that spend a lot more time writing tests (which create larger commits) etc.

<comment><USER6> I agree, for all the time he spends on his results, as far as I can tell he never really defends the idea that commit size is in any way a good proxy for "expressiveness." It would be nice if he could explain why he chose commit size over somthing like rosetta code size or some other metric.

<comment><AUTHOR> I quickly mentioned it in the caveats section up top. The underlying justification/assumption is that commits are generally used to add a single conceptual piece regardless of which language it's programmed in.

As for why this metric and not others, it's the one I could actually get the data for. I don't have the time or space to download literally millions of repositories myself, so I used what I could get access to.

<comment><USER7> _The underlying justification/assumption is that commits are generally used to add a single conceptual piece regardless of which language it's programmed in._

That is only true in some programming communities.

Essentially what you are selecting for is languages whose users seem to have digested some of the same software development memes that you have. Those users are going to be generally drawn to expressive languages, and will have very focused commits in those languages. So there is a correlation between expressiveness and small commits.

But it is only a correlation. For instance I've programmed in both Perl and Ruby. Of the two, Ruby is more expressive. (Universal opinion of everyone that I know who has programmed both.) However Perl is very "unhip", so people doing open source software development in Perl these days tend to be people who have been programming for some time, which means that they've absorbed a lot of good programming ideas. (Seriously, once you get past the reputation for "unmaintainable line noise", a lot of surprisingly good code is written in Perl.) Thus Perl outranks Ruby in this list.

What would be much more informative is the ratio of lines of code/commit between languages for users that have programmed in both languages. It would take more work to do an analysis on the principles of that analysis, and you'd reveal similar trends, but the analysis would be far more informative.

</comment></comment></comment></comment><comment><USER8> There is a lot of weak-ass criticism going on in this thread when the data -- whatever about its methodology is troubling -- seems to almost perfectly back up what is the common experience among programmers. Yes, copy-and-paste doubtlessly affected the numbers for JavaScript, but I am not at all surprised to see JavaScript where it is.

Does anyone here really doubt that you can get more done with a single line of Python than a line of C/Java/C++? Same for Clojure/Common Lisp/Racket versus Python.

We might not take individual ranking too seriously, and none of this affects language choice when performance is a critical concern (though the spacing between Scala, OCaml, and Go is interesting and relevant to this), but do you guys honestly doubt the trend here? Does anyone have a strong counter-example? It seems like the authors may have had a decent notion with using LOC as a measure. There is no proof of this here, but I am intrigued by it.

The final conclusions in favor of CoffeeScript, Clojure, and Python are again pretty obvious. Is anyone going to suggest JavaScript or C++ is more expressive than any of these?

<comment><USER9> > There is a lot of weak-ass criticism going on in this thread when the data > -- whatever about its methodology is troubling -- seems to almost perfectly > back up what is the common experience among programmers.

So?

I mean, really, I can come up with completely bogus metrics all day, and whenever one produces results in a domain that happen to align with CW in that domain post a infographic using it, but that doesn't make that metric meaningful.

> The final conclusions in favor of CoffeeScript, Clojure, and Python are > pretty obvious, I would think.</blockquote>

So? A metric that has no intrinsic validity doesn't become valuable just because it produces conclusions which match what you would have assumed to be true (whether based on valid logic or not) before encountering the metric.

<comment><USER8> Yes, thank you for that 9th-grade science lesson.

The commenters in this thread are writing off the data because...? They decided the measure is bad? When the measure conforms to experience, it's probably worthwhile to look into it. This doesn't mean that correlation implies causation and yada yada 9th-grade science lesson.

<comment><USER9> > The commenters in this thread are writing off the data because...? They > decided the measure is bad?

Yes, because what the measure actually measures isn't a valid proxy for what it purports to measure.

> When the measure conforms to experience, it's probably worthwhile to look > into it.

No, if the adopted proxy (here, "LOC per commit") has some sound rationale for being used as a proxy for the actual quality of interest (here "expressiveness"), then it is worth actually getting some results with it for which you have a firm expectation of what those results would look like if you were able to directly measure the quantity (in this case "expressiveness") for which you are using the proxy (in this case "LOC per commit").

If after such testing the proxy -- which you first looked to for reasonableness, and then tested on the "simple" data for which you had a firm expectation of what the results would be for the quality of interest -- seems workable, its worth investigating what kinds of results in returns for things which you don't have a firm idea of where they would fall. (Which is the only reason you actually use a proxy measure for in the first place.)

In this case, the proxy fails at the first test (sound rationale for using it as a proxy for expressiveness), which makes the second test (do the results line up with what you'd expect on a known sample set) meaningless.

<comment><USER8> Obviously I and the writer of the article disagree with you that it fails the first case.

<comment><USER9> > Obviously I and the writer of the article disagree with you that it fails > the first case.

That's hard to tell in your case, since most of your commentary has been explicitly skipping past the criticism of the failure of the proxy to have a clear link to the thing it was taken as a proxy to say that doesn't matter since the results were about what you would xpect, rather than actually addressing the criticism.

So it sounds like you were failing to understand the first test more than you were disagreeing with the criticism based on it. And, as yet, you haven't stated any _reason_ for disagreeing, just continued to skip to the second test.

<comment><USER8> The supposition is that a more expressive language lets you do more with a single line of code on average than a less expressive language. The second supposition is that commits tend to be done to gather code expressing a single chunk of functionality in a program, so that on the average commits have the same utility in terms of what they contribute to the source project.

It's clear from this, I would think, why therefore length-of-commit is supposed to be a good proxy for measuring expressiveness.

To be clear -- the reason that it is obvious that I and the author disagree with you on the first case is because your objection was a) an elementary one and a consideration important to all such investigations, therefore it would be considered by anyone doing such an investigation or analyzing one and b) we were disagreeing with you anyway.

<comment><USER9> > The supposition is that a more expressive language lets you do more with a > single line of code on average than a less expressive language. The second > supposition is that commits tend to be done to gather code expressing a > single chunk of functionality in a program, so that on the average commits > have the same utility in terms of what they contribute to the source > project.

There's no really good reason to suspect that the second of these suppositions holds _to the same degree across different languages_ (which basically is equivalent to the assumption that development practices are independent of language.)

> To be clear -- the reason that it is obvious that I and the author disagree > with you on the first case is because your objection was a) an elementary > one and a consideration important to all such investigations, therefore it > would be considered by anyone doing such an investigation or analyzing one > and b) we were disagreeing with you anyway.

It would clearly be considered by anyone _competent_ doing such investigation, but since your first post on this thread didn't acknowledge the basis and challenge the correctness of the common criticism in the thread based on concerns of this type but explicitly and emphatically stated a lack of understanding of what the complaints were about, it appeared quite clearly that you didn't get it. The assumption of basic competence may be warranted, if only out of politeness, when someone doesn't explicitly state something inconsistent with that assumption, but when they do, that assumption becomes unwarranted.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> The good thing about Coffeescript is that it actually seems to deliver what it was promising in the first place, terseness, expressiveness, simplicity and good Javascript output.

It is really a joy to develop with (though my being a Ruby programmer probably makes me a somehow biased and enthusiastic candidate).

</comment><comment><USER11> Now I want to see the same thing, but based on the length of the commit message instead.

</comment><comment><USER12> Wait... JavaScript and CoffeeScript end up at _opposite_ extremes while having near-enough identical semantics?

That's a big red flag on this as a measure of expressiveness.

</comment><comment><USER13> It's hard to tell if the fact that CoffeeScript is #6 (the highest ranked major language) and Javascript is #51 (second to last) is a reflection on how much of a shift CS is from JS, or on the quality of methodology and metrics in the OP.

<comment><USER14> I'm thinking that's mostly due to the testing methodology. In JS it's pretty common to start a project by downloading and committing jQuery, Underscore, and whatever framework dependencies you're using. And just speaking from experience, coffeescript is better, but it's not _that much_ better (I'd guess ~1.5 lines of JS per line of CS, the chart shows somewhere around 8:1).

<comment><USER15> Coffeescript, I find, is more apt to force you into a more cohesive pattern for structuring your code which could help avoid large refactoring stints.

</comment></comment></comment><comment><USER16> > let the results speak for themselves

The difference between Fortran Free Format and Fortran Fixed Format should be enough to tell us that _lines of code per commit_ is all about how much stuff you put on a line!

(Is `nl` significant in the language syntax? Were readable wide screen displays available when the code was written?)

</comment><comment><USER17> Note that in fifth place -- ahead of Coffeescript, Clojure, Python, etc., etc., -- is eC, a that's basically C plus a few OO features and a GUI library. It has, for instance, no automatic memory management (besides some rather primitive refcounting); neither dynamic typing nor type inference; no nice literal syntax for collection types; in short, whatever its merits it is not an outstandingly expressive language.

There is surely some correlation between short commits and expressiveness, but they're far enough apart that I think the title is very misleading.

</comment><comment><USER18> Terse isn't the same as expressive. Consider Scala vs Java. In Java, definining a singleton involves implementing a design pattern in one of a few ways. Maybe you have a private constructor and a static initializer. In Scala you define your class with `object` and it's done. That's concise and expressive.

In Java, if your generic class has a lower bound you write Class Foo<T extends Bar> while in Scala you write def Foo[T<%Bar] which is just an abbreviation. Replacing a word with punctuation. One is good, one isn't.

</comment><comment><USER19> The real measure is features shipped.

It's pretty hard to disambiguate speed of development, fluidity and flexibility (which potentially increases LOC per commit by bundling multiple 'conceptual pieces') with expressiveness (which decreases LOC per commit) in a single LOC per commit metric.

The idea that a single commit corresponds to a 'single conceptual piece' is probably not very precise. It also doesn't measure for the complexity of the conceptual piece. It hasn't been established that the same level of 'conceptual pieces' are tackled across all programming languages per commit.

Just some thoughts. That said, I think though given all the factors involved (more expressive concepts per commit are perhaps tackled in more expressive languages, and that cancels out that less expressive concepts are tackled per commit in less expressive languages -- that balances out simplicity in simpler / less expressive languages can lead to more actual features commited), that actually the methodology kind of works. But, like others here, I wouldn't presume it's quite so simple underneath.

</comment><comment><USER20> There are a few surprises in that list. I'd have thought both Coq and Lua would end up further to the left. I suppose the graph shows an interesting dynamic: expressiveness is not just due to a language's semantics, nor syntax, nor libraries. You need a healthy interplay between all three aspects of a programming language to truly be "expressive".

</comment><comment><USER21> The whiskers on the Prolog and Logtalk plots would tend to confirm what PG had said in one place or another, that a language can be both more high level and less expressive, apparently using a definition of expressive related to line count. In that light I'm kind of surprised they do as well as they do in this post.

As I get more serious about Prolog I think it's kind of a shame more people aren't exposed to it (apart from apparently dreaded university classes). It's pretty impressive just how quickly one can write a parser, and for writing an "internal" DSL it rivals or exceeds Lisp (depending on one's taste).

</comment><comment><USER22> Hah! Take that, Python aficionados!

\-- Perl user

<comment><USER23> What matters more is how much is expressed to you when you have to read your own code again in a year - or when someone else does

\-- Python user

</comment></comment><comment><USER24> This assumes that languages are used to solve similar classes of problems, or that, in aggregate, those different classes result in similarly-sized "feature" chunks.

I think it's fair to say that nobody's ever written a forum in puppet, and that few people are working on micro-[web]frameworks in Fortran.

Interesting data, just need to be careful about what conclusions are drawn from it.

</comment><comment><USER25> Does this data take into effect the total lines of code in the project being committed to? Would this not have an effect on the results?

<comment><AUTHOR> No, it's a combined total across all ~7.5 million open-source projects in Ohloh, so (potentially real) effects like that are averaged out.

</comment></comment><comment><USER26> No sign of RPL, which is insanely expressive :(

<comment><USER27> Are you referring to the programming language for calculators? Wikipedia doesn't make it seem that expressive, and I can't find much else associated with the acronym RPL.

<comment><USER26> Yes. The Wikipedia article is to be honest, crap. RPL is a functional stack based language sort of like lisp and forth combined with mathematica thrown in for good measure.

Its both compiled and interpreted and a system language and a user language. Couple of examples:

'X=Y^2' 'Y' SOLVE 149 'X' STO EVAL @evaluate first expr for Y=149 .. Including optimising it by rearranging it

{ "a" "b" "c" } SORT REVLIST << "M" + >> MAP @sort then reverse then add M string to every list item using anonymous function and map.

Storage is entirely transparent and persistent as well.

Quite my favourite language these days. I can actually do real work with it and it runs in my pocket on a 75MHz ARM (which is more than enough for it), has built in context sensitive help, a debugger that even puts gdb to shame and has 2Gb of persistent storage and lasts a month on 4 NiMh eneloop AAA's. All for £79 :)

It also doesn't have any distractions like the internet.

</comment></comment></comment><comment><USER28> >One proxy for this is how many lines of code change in each commit

This premise is complete rubbish.

</comment><comment><USER29> APL and J would win this handily, but we don't use those languages for a reason.

</comment><comment><USER30> Hm, how can Objective-J have such a different ranking than Objective-C?

</comment><comment><USER31> While their chart confirms my personal bias (that FP is more expressive), I think their methodology is flawed to the point of making the whole thing meaningless. They are not measuring expressiveness, they are measuring lines of code per commit. Having a community that likes lots of small commits doesn't actually make a language more expressive than one with a community that likes fewer, larger commits. They even acknowledge that the javascript numbers are basically meaningless because it is so common to copy+paste entire big external dependencies into a javascript project.

<comment><USER32> I'd agree, I'd expect something like APL to show up on here in terms of sheer expressiveness. While it can be a pain to program in because of the funky characters, it's actually very very expressive.

<comment><AUTHOR> APL is insufficiently popular to be considered here, otherwise I'm sure you would be right.

</comment></comment></comment><comment><USER33> That's why I think people should take a look at the next generation of Rebol <http://www.red-lang.org/>.

Fast as C, expressive as Lisp, and more readable than Ruby...well, that's the goals at least ;)</comment>


Show HN: Capture your real image – Zero refraction metal mirror - <AUTHOR> http://igg.me/at/metalmirror/x/9224494

<comment><AUTHOR> Hi,

The last few days have been absolutely incredible, we've attracted the attention of the world, and were marching closer and closer to bringing the zero refraction handcrafted metal mirror to life. To get there, we need your help to bring family, friends, fans, and followers to the campaign.

This crowd funding process and its soft launch has already provided us with a lot of great feedback, especially about its sizes, and interest from handmade product lovers from all over the world -- and we've been listening to it all. We observed that all are looking for more opportunities to get the metal mirror at various sizes, so we went back to our artisans and came up with a solution. Today were offering metal mirrors with various sizes. We'll offer a limited number of mirrors at each level, and as each tier runs out the next ones will be made available, so act quickly to get the best deal!

We need to keep the campaign momentum going. Please help by sharing the news and, of course, keep pledging!

[http://igg.me/at/metalmirror/x/9224494](http://igg.me/at/metalmirror/x/9224494)

George! CEO

<comment><USER2> All the best.</comment></comment>


Amazon TV ad gives sneak peek at 'Paperwhite' Kindle and new Kindle Fire - <AUTHOR> http://www.geekwire.com/2012/amazon-tv-ad-shows-paperwhite-kindle-kindle-fire/ <comment><USER2> It would be very cool if the "paper white" display actually lives up to its name. The lowish contrast on even the latest models is disappointing.

Then if they would add proper foreign language support (full CJK fonts, real vertical text layout, ruby support), maybe I could finally get a kindle!

Oh, and epub. An e-reader without good epub support is silly.

Who am I kidding... :(

<comment><USER3> Haha, yeah. I bought a Chinese textbook on Kindle and the Chinese characters were scanned. Worse, the scans were pasted into the wrong parts in some spots, mixing up phrases and translations, and they didn't zoom with the font size. Their Asian language support is atrocious, I guess.

</comment></comment><comment><USER4> Direct link to the ad: <http://www.youtube.com/watch?v=2EQ0e7dYuaI>

</comment><comment><USER5> Soooo it looks like the DX is still the red-headed stepchild.

OK, I get it, I'm a niche customer. But I would happily pay exorbitant markups if they kept updating the DX screen and software.

<comment><USER6> The DX is so much better than the normal Kindle, why can't Amazon just wait and let the market develop? Given a few years, I think it would do just fine.

Right now I'm not upgrading until I see a DX formfactor, no matter what the new features are. I like my printed page the size of, well, printed pages.

<comment><USER7> Convince me.

I like reading on the size of a paperback. Why do I want some giant printed pages.

<comment><USER8> For me, code listings are too small on the small Kindles, even when the books are bought from Amazon. Also it's a bit distracting to me to turn the page as often as is required on the small Kindles, which fit much less words per page than a paperback.

<comment><USER9> I've given up on reading any technical books on any device. Even on an iPad it's a pain to try to read books that are formated with items that are not inline with the text.

</comment></comment></comment></comment></comment><comment><USER10> Does anyone know why books are the size and shape that they are? Is it optimization over time for users or because it fits better in a truck pallet? Or something else? Suit pockets maybe?

<comment><USER11> There's an explanation in Mark Forsyth's excellent The Etymologicon claiming it's based on the size of sheepskin.

[http://books.google.co.uk/books?id=KUZxTvay3PMC&lpg=PP1&...](http://books.google.co.uk/books?id=KUZxTvay3PMC&lpg=PP1&pg=PT50#v=onepage&q=papyrus&f=false) (I can't seem to get a direct link to the page, but just click page).

</comment></comment><comment><USER12> I was bartending during the Giants/Cowboys game, saw this ad and for a minute wasn't sure if I had seen a new KF or not. But if so, it looked crazy thin. Christmas 2012 looks to have a salvo of great devices going around this year

</comment><comment><USER13> Wow, look at that refresh rate! Hopefully it's not a case of "Screen images simulated."

<comment><USER14> The latest four-way-controller ones are pretty good for refresh rate, I turned down the earlier kindles but am totally happy with this one. A couple of extra years development would seem to match up well with expectations of a faster refresh.

I just hope that they have a non-touch version (though I'm not willing to bet on it).</comment></comment>


Ask YC: Best computer components shop around Palo Alto? - <AUTHOR>

Fry's is pretty good, but sometimes I need an alternative.  For example, Fry's doesn't have the new Penryn (45nm) Intel processors even though a number of internet retailers have them in stock.  GamePC on California Ave has a good selection but not so good prices.  Is there a newegg-like retailer within driving distance (radius out to San Jose)? <comment><USER2> I like HT Computer Warehouse <http://www.htcw.net/index.html> for used stuff.

</comment><comment><USER3> This might be slightly off topic but for harder to find parts you should check out Weird Stuff Warehouse in Sunnyvale (it's close to Yahoo). The people are pretty friendly and it's generally just a fun place to go poke around.</comment>