Bloomberg Users' Messages Leaked Online - <AUTHOR> http://www.cnbc.com/id/100733073

<comment><USER2> It is a bit of a cluster for Bloomberg. From the article:

"The messages had been found, a financial markets professional said, through a simple Google search. They were taken down from the internet on Monday, after the FT inquired about them.

They showed information such as unique Bloomberg user identifiers, real names and traders' e-mail addresses as well as confidential financial price information and trading activity."

and supposedly unrelated:

"... Goldman Sachs had complained that the news organization's journalists had been able to track when users accessed their terminals and which functions they used."

</comment><comment><AUTHOR> This is very interesting. I work with traders at one of the big banks mentioned in this article and I can totally see how this leak could be impactful. Traders exchange pricing information all the time on BBG messaging.

<comment><USER3> Not to mention that some of the Libor fixes were discussed over IM.

</comment></comment><comment><USER4> Anyone having a link to the "backup" of these?

</comment><comment><USER5> That was fast...see prior comment on this issue:

<http://news.ycombinator.com/item?id=5698514>

</comment><comment><USER6> I find it interesting that people used this because of its usefulness and security.

</comment><comment><USER7> It'll be interesting to see how the security breach came about...something trivial that was previously protected by obscurity? Lots of people have never used a Bloomberg terminal, and its main clientele don't seem like the type to heavily security test it for fun.

<comment><USER8> _something trivial that was previously protected by obscurity?_

It appears this is very much the case- Bloomberg insiders have known for years that you can access anyone's information- and have publicly stated as such. I suppose people didn't realise the dangers contained within that before now? Seems odd, but still.</comment></comment>


Direct Benefit Transfer for internet data packs instead of Free Basics - <AUTHOR> http://blogs.timesofindia.indiatimes.com/toi-editorials/free-basics-is-a-walled-garden-heres-a-much-better-scheme-direct-benefit-transfer-for-internet-data-packs/?utm_source=TOInewHP_TILwidget&utm_campaign=TOInewHP&utm_medium=Widget_Stry <comment><AUTHOR> Little background about the author: Nandan Nilekani is the ex chairman of Infosys, the first "big" company to start in India, and UIDAI is Indian equivalent of social security number, which was his brainchild</comment>


Stop hand coding, start Zen Coding - <AUTHOR> http://whiletruecode.com/post/stop-hand-coding-start-zen-coding

<comment><USER2> No. We're not doing it wrong.

I am hand coding HTML in nXML mode in emacs. I'm also hand coding various templating languages/libraries which generate HTML. Nothing's wrong.

What the OP is doing wrong is writing bad titles for posts about an otherwise decent tool, Zen Coding. Better to skip the post and just read about Zen Coding directly: <http://code.google.com/p/zen-coding/>

</comment><comment><USER3> Zen Coding is great.

Idiotic headlines are not.

There are hundreds of reasons to hand-code HTML, and this article addresses why one of them is inefficient.

<comment><USER4> Fair enough, but headlines like this will probably stick in people's minds so that they next time they go to hand-code a repetitive block they'll remember to try Zen Coding it.

<comment><USER5> I prefer accurate statements to catchy statements.

</comment></comment></comment><comment><USER6> If you are doing "table-based layouts", you're doing it wrong.

I'm a great fan of zen, specially for CSS, but every editor has had autocomplete/expansion for years, and it ends up being nearly the same speed (t+tab, tr+tab, td+tab, cmd+alt+d x5) once you internalize it. I even ended up removing it from ST2 since it conflicts with default shortcuts. CSS is a whole different story, I haven't seen any editor with expansions as complete as Zen.

<comment><USER7> If you decide to preach, it helps to know the subject.

Table-based layouts is the only practical option for HTML emails, which is exactly what these guys were doing.

<comment><USER8> From the article:

> writing an XSLT stylesheet to transform an in-memory representation of a > customer's bill into an HTML version for display on our site.

If you decide to counter-preach, it helps to read the article and understand it first.

</comment></comment></comment><comment><USER9> Honestly? I don't get why this is quicker. Doing front-end development, writing actual HTML tags surely account for less than 1% of my time. And most of _that_ time is just modifying existing structures, not creating new ones.

I'd rather type a few closing tags myself, and use copy-paste to duplicate a bunch of lines. I really don't see how that is going to take longer in the end.

</comment><comment><USER10> Lets say only the second 'li' in:

div>ul>li*5

Needs the class "active"? While this may seem simple, I feel a tool like this should be able to handle something extremely simple. What it looks like is I have to write an entire conditional.

There is something to handwritten code that (to me) will always seem more beautiful than machine generated code.

</comment><comment><USER11> If you spend time worrying about how to reduce how much time you are wasting on HTML you're doing it wrong.

Over the past year I've spent about 4 weeks just thinking about how to construct the data structure I need to solve one hairy problem or another. I've spend _maybe_ a day writing html over the entire fucking year.

Don't optimize the easy parts.

</comment><comment><USER4> Here's the list of official plugins from the Zen Coding team for all supported editors: <http://code.google.com/p/zen-coding/>

</comment><comment><USER12> The misleading title of the article is equivelent to making statements like: "If you're driving manual transmission cars instead of auto, you're doing it wrong" or "If you're eating food that needs to be prepared before eaten, you're doing it wrong"

I don't see any problem hand-writing HTML at all, in-fact you get to a point in your development career when you can type sufficiently fast enough to beat out even some of the best auto completion functionality an IDE or third-party library/plugin can offer. Zen Coding definitely has its uses, but I don't really remember the last time I had to hand-write much HTML at all anyway. I use the HTML5 boilerplate as a basis for my projects, if using Wordpress I use a barebones Wordpress theme or if I am developing a HTML newsletter I'll use the HTML email boilerplate.

</comment><comment><USER13> I definitely disagree, especially given that their example for its efficiency is "table-based layouts". That's a huge no-no. Tables are for tabular data only.

<comment><USER14> eh, religion

<comment><USER15> Sure, except if you've worked with full web pages made of tables throughout, you know how they usually suck in terms of maintenance and how hard it is to make changes. It's also just a lot more boilerplate compared to doing it "the right way".

But if you know what you're doing, and you know why exactly you need a table here to do this particular thing (which should not be your entire web page due to maintenance issues), then go ahead and use a table. Like for emails it's pretty much a necessity (along with style attributes, sigh).

</comment></comment></comment><comment><USER16> Since I started using HAML, I can't stand writing HTML. If I ever need to write HTML again, I'll be sure to remember Zen Coding.

</comment><comment><USER17> I like Zen Coding a lot, specifically for CSS. HTML, it's ok, but not always faster IMO. The list example is a good one because I think it's an easy 'this is better' use-case, but for most things that don't require multiple instances of something it's not adding much (and that's ok, there's only so much you can do there).

For this nested table example, it's great. Another multiple instance example. There's probably no easier way to pump out that code so fast, but if it were a standard table, anything will do, even the hated (by most on here) WYSIWYGs, that could drop a customized table in a few clicks.

</comment><comment><USER18> I use block folding and a clipboard to achieve a similar effect. Is there really anyone, who, when faced with this task, would manually type 500 lines of repetitive html by hand?

</comment><comment><USER19> HTML is not the problem when you're designing. For an experienced front-end developer the gains are minimal.

A more significant part of the time spent creating a webpage is wasted on CSS (or in javascript but I don't put it in the same boat). So if you have to optimise your process it's more efficient to learn something that will improve your css workflow (Sass, Compass, Less) than to add a layer above your html code.

</comment><comment><USER20> No thanks, more trouble learning the basics of Zen Coding than it would take for me to just hand write that HTML.

If it works, don't fix it.

</comment><comment><USER21> This is a really misleading title, I thought they were implying that you should use a WYSIWYG editor.

</comment><comment><USER22> I love Zen-Coding for stuff like this:

        html:5>(div.header>ul.nav>li>a[href="javascript:"]#menu$*6)

It's a complete HTML template in a one-liner...

        <!DOCTYPE HTML>

          <meta charset="UTF-8">
          <title></title>

</comment><comment><USER23> Took a couple minutes to whip up a command-line utility [1] in Python. Doesn't have much use - just looking for something to do!

[1] <https://gist.github.com/2841106>

</comment><comment><USER24> If you're using XSLT, you're doing it wrong.

(I'm only kidding around...sorta.)

</comment><comment><USER25> I don't edit HTML very much, but when I do, Zen coding helps so much. Especially since all you really need to know is CSS selector formatting.

</comment><comment><USER26> I dont hand code HTML. I write a small bash script to hand code it for me.

</comment><comment><USER27> I just wasted my time...

<comment><USER28> This article pays time

</comment></comment><comment><USER29> Thought about using some preprocessor? Jade?

</comment><comment><USER5> The end result is the same. Who are you to tell me how I should arrive there? I don't write vanilla HTML, but your tool of choice doesn't need to be mine. That's a choice for the individual to make and whatever they decide is fine. What's not okay is trying to make that decision for them or telling them that their choice is inferior.

It's not. Though your thought process might be.

Get some self esteem so you don't need to author posts insulting strangers.

</comment><comment><USER30> Majoring in the minors?

Who actually spends the majority of their time editing html?

<comment><USER31> Web design companies and others design everything in Photoshop/Fireworks. There are many people who's entire job it is to create 4-7 page websites from scratch, in a day or two. And that involves lots of HTML writing, and time pressure.

<comment><USER30> Sounds like a terrible way to live.

</comment></comment></comment><comment><USER32> Tab completion included standard in many editors is just as efficient. Linkbait title but Zen is cool.</comment>


StackOverflow ain't dead (and it keeps evolving) - <AUTHOR> https://zeitkraut.de/posts/2015-07-18-stackoverflow-aint-dead.html

<comment><USER2> I rarely post now on StackOverFlow and each time I do I wonder if it's my last time as I'm told I'm in danger of being barred because of my inability to post a question correctly. Also some serious trolling happens if one asks anything deemed obvious - just insecure bullies.</comment>


Palo Alto's last remaining mobile home park is running out of options - <AUTHOR> http://www.theawl.com/2014/12/the-trailer-park-at-the-center-of-the-universe

<comment><AUTHOR> > he average home price in Palo Alto has skyrocketed from six hundred and > forty thousand dollars in 2000 to two million dollars in 2014

That's way above national average</comment>


Publications by Googlers - <AUTHOR> http://research.google.com/pubs/papers.html

<comment><USER2> I also noticed that someone recently posted a list of publications by Microsoft Research (MSR), presumably to contrast with Google's publication list. MSR does some amazing academic research, but it's not a fair apples-to- apples comparison to compare their publications with Google's, since the primary output of MSR is academic research papers (that's why the lab was founded!), while the primary output of Google is free web-based consumer products :)

</comment><comment><USER3> I hear that some core Google tech papers are usually two to four years old by the time they're published. Is that true?

<comment><USER4> Sadly, it's true and not uncommon for academic research as well...

<comment><USER2> for academic research, oftentimes it's not a matter of keeping results secret for years before publishing ... it's simply because the academic peer review and publishing process has such high latency

<comment><USER5> Also, preprints can be passed around for months or years before something is published in a peer-reviewed journal.

<http://en.wikipedia.org/wiki/Preprint>

</comment></comment></comment></comment><comment><USER6> Is it just me? This list seems too short. Google is (as far as I can tell from outside) a great company in many respects, but their Achilles heel is their obsession with secrecy. It has some advantages, but I fear they may be outweighed by the disadvantages which include lack of early feedback on usability and a susceptibility to NIH syndrome.

<comment><USER7> Well, the full list makes it seem a lot bigger: <http://research.google.com/pubs/papers_by_year.html>

But considering they have over 25k employees, it may not seem a lot. But given the depth and quality of such publications, I think it is quite a fair number.

<comment><USER8> That is also not a complete list.</comment></comment></comment>


The High Price of Being Single in America - <AUTHOR> http://www.theatlantic.com/sexes/archive/2013/01/the-high-price-of-being-single-in-america/267043/ <comment><USER3> This is unusually bad writing for the Atlantic. The article concludes: "Our lower-earning woman paid $484,368 for being single. Our higher-earning woman paid $1,022,096: more than a million dollars just for being single."

Breaking down those numbers, $381,600 (79%) and $763,200 (75%), respectively, of each person's additional cost comes from living arrangements--the fact that married women spend less on housing than unmarried women of the same income level.

They say: "We did consider that the discrepancy was in part due to the simple logistical fact that two people can split a rent or mortgage. However, other less obvious factors also come into play."

They wave their hands and point to discrimination against single people in finding housing, but then completely avoid trying to quantify those effects and just use the big number. No shit it's cheaper to split a household with someone than to live alone. That's one of the purposes of getting married.

The same is true for the "health spending" category. They again wave their hands about "discriminatory policies" but fail to actually point out a single policy that might explain higher healthcare expenditures by singles. They point out that married disabled people fare better, because they can combine their incomes, but that again reduces to the obvious argument that it's cheaper for people to couple up than to try and live alone.

The whole income tax calculation ignores the fact that around half of couples (I've seen figures from 40-60%) actually pay a tax penalty to get married. My wife regularly (half-)jokes that we should get a divorce to save money.

<comment><USER4> The spouse's income is described in para. 7 (depending on how you count):

"Our married women's husbands worked too, earning $51,000 and $103,000 respectively."

<comment><USER3> Thanks. Corrected.

It's interesting they set the husband's salaries based on the idea that women earn $0.78 for every $1.00 earned by men, but fail to account for the fact that a woman who stays permanently single is far less likely to suffer the reduced lifetime earning power that comes from having kids.

<comment><USER5> I also found it interesting that they pick the women's salaries from statistical averages, but don't do the same for men, but just extrapolate based on some hand waving guess of a multiplier.

</comment></comment></comment></comment><comment><USER6> The article misses the entire point of civil marriage in the first place, which is to provide incentives for a structure historically seen as positive for society, not to give individual people what they want. We provide (dis)incentives for all kinds of activities, of which marriage is one. Charitable giving and smoking are a couple other areas we try to nudge behavior with tax policy.

The authors are people in one sphere of society saying they don't like laws that incentivize behavior that is different from their own. But nevertheless, they are making a conscious choice (even with information about the additional economic costs etc.) to remain unmarried, which includes associated costs and everything else that comes with that choice.

In their case, we all win in one sense. Society gets some additional tax revenues to support social services, and the authors get something they prefer instead: singleness.

Not all of our preferred behaviors are given incentives by the government; only the ones considered compelling and in the public interest. Civil marriage primarily exists for the state; not really for you.

Note: Sure, there are good and interesting arguments about the social value of civil marriage, whether or not it should even exist, and if so, in what form. I'm not going there. I'm just pointing out that the authors are making a conscious economic decision and are disappointed that they pay an added price.

<comment><USER7> We do not exist for the benefit of the state, the state exists for the benefit of the people. Stop using tax resources to discriminate based on lifestyle choices.

<comment><USER8> Let's suppose hypothetically, for the sake of argument, that numerous careful, politically neutral scientific studies have been conducted, and they reveal that children who grow up in two-parent homes have significantly better outcomes -- fewer suffer abuse and neglect; on average they get better grades; they have more education and get better jobs; they live longer, healthier and happier lives.

Let's suppose these studies correctly controlled for all conceivable other variables like race, income level, education, profession, etc.

Don't we owe it to those children to make sure that as many as possible are born into two-parent families? Isn't a financial incentive to marry a great way to balance society's interest in maximizing the well-being of its future citizens in this way, while still allowing its citizens who desire alternative lifestyles the freedom to do so?

I have no idea whether real studies have been conducted that are similar to my hypothetical ones. But based on personal experience and anecdotal evidence, and without knowledge of scientific evidence to the contrary, it seems reasonable to me to assume that heterosexual two-parent families generally have better outcomes.

<comment><USER9> Then let's suppose there's a study that shows children who grow up in a rich family grow up healthier and happier and have better education and better jobs. Don't we owe it to those children to make sure that as many as possible are born into rich families? Raising children as single parents is already hard enough, a financial disincentive for them will only make matters worse.

</comment></comment></comment></comment><comment><USER10> Get rid of marriage from the tax code entirely. If you both make near-equal income, there's not a marriage benefit, but a marriage penalty. My wife and I pay $5-10k more a year in taxes because we decided to get married. The tax- code still encourages the old paradigm of one breadwinner and one person staying home to take care of the children.

<comment><USER11> Get rid of marriage from the law entirely. Marriage could be expressed in a standard contract that gives the sorts of rights the it currently carries. The state shouldn't have any say in who enters this sort of agreement.

<comment><USER12> This was Mitt Romney's suggestion for gay marriage, but the truth is that there are all sorts of rights that can only be conferred by marriage. For example: you can't write a contract that says your business partner should pay less taxes, but marriage can. You can't write a contract that gives your business partner the right to a green card, but marriage can. There's literally hundreds more.

We are a species that likes to pair-bond; we consider it a greater hardship to separate members of a pair than members of a looser association like friendship. The legislation reflects that. Social engineering via tax breaks are a dumb idea, but deleting the concept of marriage from law entirely is impractical and probably undesirable.

<comment><USER4> I am torn, because I want to upvote your first para which accurately addresses the points raised by the parent; yet your second para is all fluff, empty rhetoric, assertions totally without justification.

If you are a new kind of troll, I salute you.

<comment><USER12> It is never my intention to troll, as I hope my commenting record attests. Which of my statements do you consider unjustified?

<comment><USER4> I was thinking specifically of the statement "[D]eleting the concept of marriage from law entirely is [...] probably undesirable."

</comment></comment></comment></comment></comment></comment><comment><USER13> "Insurance policies—ranging from health, to life, to home, to car—cost more, on average, for unmarried people compared to those who are married."

Well, the actuaries actually process statistics on why rates should be lower. That has nothing to do with gvt and everything to do with statistics. I'll buy an actuaries reason over the govt, as they are specifically doing this to make the most money for the insurance companies.

<comment><USER8> The question that comes to my mind is, which of the following situations is true?

A) Marital status is an input to the insurance model. If all other inputs but marital status are changed, the model outputs different values, and the marriage is lower.

B) Marital status is correlated with other factors, which are input to the insurance model. For example, it is quite conceivable that individuals who are either very young or very old are likelier to be unmarried, and also likelier to be higher risks for many types of insurance (e.g. a young driver is risky due to inexperience, an elderly driver is risky due to declining faculties and health problems that interfere with driving).

</comment></comment><comment><USER14> As an Indian, and asking purely from a cultural perspective how is the family system in America?

This might very well be stereotyping but the impression we have about US is that divorces are very common and marriage rates are low. And the family system is pretty disintegrated. There was a article posted here few days back on how a guy was sleeping on the streets while he could stay with his sister. That sort of thing is not imaginable here in India.

Also being married has its own advantages. Regardless of whatever the feminist movement believes. Married women do get a great deal of financial security, physical security and comfort by the very virtue of the way marriage is structured.

Something that is seen to be happening here in India is increased rates of Alimony claims, false dowry cases and super powerful laws in favor on women(which seem to be abused currently) may lead to problems like these.

This article makes a nice read.

<comment><USER15> I realize that since you are Indian, your culture is your basis of comparison and contrast with the US, but you should be aware that India and other South Asian countries consistently rank among the worst on Earth in international humanitarian organizations' analyses of women's rights.

I'm married, I think being married is great, and I also know that America has some serious social ills, but I would never trade America's "disintegrated family system" for the current system in India where numerous forms of violence against women are so rampant. A little bit of feminism would do Indian society a lot of good.

<comment><USER14> >>but you should be aware that India and other South Asian countries consistently rank among the worst on Earth in international humanitarian organizations' analyses of women's rights.

Not denying. You are very correct.

But I guess not all form of oppression include hitting, beating and other forms of violence.

Leaving a women all alone to herself and asking her to earn a million dollars more than a man merely to survive is nothing short of a slow torture in itself. Something against which you cannot scream, complain, whine or even expect others to show sympathy about. In the name of freedom this is just bonded labor of a different kind.

Freedom(or a illusion?) is of no use when you tell a woman she can do whatever she likes in the time left after a 15 hour work schedule, tending to kids and other needs of her dependents.

Coming to India's problem with violence against women. It looks big also because of the mere population scale you are looking at. Although I agree with you as a society we have a long way to go when it comes to protecting women.

</comment></comment></comment><comment><USER16> While I agree with the general premise...

I'd love to see these numbers run again, but with a child or two thrown into the mix at marriage, or 5/10 years down the line.

Many societies try to promote childrearing via tax benefits - our just has it structured primarily through a marriage credit.

<comment><USER17> I had that thought too, but they sort of addressed that. Per capita, child rearing costs single women more than married women. That's because married women get to split costs with husbands.

If you look at divorce statistics, for all that men feel that they get screwed, after a divorce the ex-husband usually has a significantly better standard of living, and the ex-wife and kids wind up worse off. (My source for that is _The Price of Motherhood_ which is a fascinating book, but was not exactly the most comfortable book for my wife to have found while pregnant with our first.)

Thus if you add in children, marriage becomes an even better relative deal for women.

(Note that all figures that they offer are aimed at women, and not men.)

<comment><USER18> I think the biggest complaint from men in divorces is not that they get screwed _economically_ , but that the courts are heavily biased towards giving the mother the _children_. Sometimes "standard of living" isn't the most important factor in play - otherwise custody cases would be two parents trying to make the other one take the kids, instead of the other way around.

I haven't done the research to make the argument that their complaints are _true_ , (though I think it is), but you are somewhat misrepresenting the complaint.

I've never been married, divorced, or had children, so if I am missing something obvious, please let me know.

<comment><USER17> Statistics that I've heard on that one. A significant majority of the time, children go with the mother. In a significant majority of cases where fathers contest custody, children go with the father. This is at least in part because the father usually has better finances, so can make a persuasive case that he'd be in a better position to be a caregiver.

That said, it is very common for men to _threaten_ a custody dispute then back down with some other concessions. It is difficult to tell how often this is because he didn't think he'd win, or preferred the concession.

My source on this is the same book.

Disclaimer, I've been married over 20 years, 2 kids, never divorced.

<comment><USER19> > In a significant majority of cases where fathers > contest custody, children > go with the father.

I have a fair amount of familiarity with family law (not a lawyer though) and I have to say this is hard to fathom. To my knowledge fathers have to basically prove gross negligence or substance abuse or other criminal activity by the mother in order to stand a chance of winning physical custody. It is generally presumed that kids are better off with the mother and any father seeking custody needs to prove otherwise. Having better finances usually doesn't factor into the decision AFAIK -- if the father has better finances to support the child, he can do so with child support.

<comment><USER17> I was quoting from a book that I read 8 years and 2 moves ago. But the best that Google turned up is the very dated [http://www.amptoons.com/blog/files/Massachusetts_Gender_Bias...](http://www.amptoons.com/blog/files/Massachusetts_Gender_Bias_Study.htm) that found that when fathers choose to contest custody, 70% of the time they win sole or joint custody.

I have found elsewhere a claim that usually this is joint, so women are still coming out better. This seems believable, but that claim was not sourced.

Several places I found the claim that women receive sole custody about 70% of the time, joint custody 20% and men get sole custody a bit under 10%. But also the majority of custody cases are not settled by a judge, so that proportion does not speak to what happens when a judge makes the choice.

So I should put a question mark next to the specific claim that men who contest, have a good chance of getting custody. Because I don't have good sources to back it up.

</comment></comment></comment></comment></comment></comment><comment><USER20> "The husbands' salaries to reflect the fact that a woman earns 78 cents for every dollar a man earns"

If that were actually true, why would any business hire a man when they could get the same work for less?

<comment><USER21> It's rarely the case that an equally skilled woman earns 78 cents for every dollar a man earns. There are a wide variety of factors that lead to the wage gap.

      * Women take more time off for child-rearing
      * Women still devote more time to household tasks + children
      * Women are more likely to choose careers for reasons other than money
      * Discrimination against women surely plays some part
      * Women are less likely to negotiate salary
      * Assertive women are often perceived negatively, unlike assertive men.

There are many others. But if you take a male and female, and put them in the same job for three years straight out of college, there won't necessarily be much of a wage gap. In some cases the women earn more.

<comment><USER22> Men are also more likely to take dangerous jobs that are more likely to get them killed, which pay better

</comment></comment></comment><comment><USER23> This is a crock, the social purpose of marriage is raising children that are properly socialized to inherit society the financial benefits are there to help partially defray the cost of raising children. And as was stated below throw some kids in and see how the numbers work out.

<comment><USER24> I know you did not mean to offend me, but whenever I see this "married families raise better kids" line I take offense. I was raised by a single mother and a tight knit extended family (grandmother+grandfather+uncle). I was showered with love and parental affection/guidance. Moreover the house I grew up in was dramatically more peaceful and nurturing than it would have been had my parents stayed married.

<comment><USER25> > I was raised by a single mother and a tight knit extended family > (grandmother+grandfather+uncle).

I don't think he implied that it is true in every single case. If you had to bet a lot of money on a random family with happily married parents vs. a single-mom, where would you place your money?

A better statement would be "families raise better kids." You had a family because you had a close extended family. That isn't a normal occurrence.

</comment></comment></comment><comment><USER26> I'm a married male with children, and this is bullshit. I recall at my first job my manager saying, "Yeah, tax the hell out of you young single rich guys". The state should have no discriminatory power of taxation w/regard to marital/reproductive status. If anything, young single people should be taxed _less_ , as they are a lower draw on social services and are more likely to deploy capital rather than save.

<comment><USER27> Tax rates are set based on a person's ability to pay, not on their expected use of social services. You could argue that this discriminates against young wealthy singles, but then you'd effectively be arguing that the impoverished or the chronically ill should pay proportionately higher taxes because they are more dependent on the state for their day-to-day wellbeing. The problems with this position should be obvious.

<comment><USER26> We're entering the area of considering charity vs. penalty. The current system penalizes those that have no need of charity doubly. Not only do they have to subsidize those more dependent upon the system, but they are penalized on top of that with more taxation. The problem with that situation should be obvious, as well.

</comment></comment></comment><comment><USER28> This was not my experience at all. When my wife and I married and combined incomes we jumped a bracket, didn't qualify for IRA withholding, tuition credits (I was in night school at the time), or DC's first time home buyer's credit. Two people with career salaries are much better off (with respect to taxes) before marriage... yes, we gamed out filing jointly and separately - <USER2> got hosed either way.

</comment><comment><USER29> This neglects "The Price of Being Married" which is rarely an instance of frugality and prudent fiscal discipline.

I'm not implying that ALL members of a married home are frivolous with their money, but it sure seems that way sometimes.

How much money does having a wife or husband cost? I'm willing to bet it's a sh*t load more - not to spread words of discouragement or anything.

</comment><comment><USER30> A huge amount of the money it "costs" to be single they get from splitting living costs. Turns out single people can and do have roommates.

The next biggest chunk is from taxes saved by being married, using contrived earnings. Turns out, that it varies wildly depending on how much each person makes. There are certainly some amounts of money where you pay less taxes being married, but there are quite a few others where it costs far more. It just depends on where you fall in the tax bracket. (Generally if both spouses make a similar amount of money the tax code hurts them, if one makes significantly more it helps.)

</comment><comment><USER31> They got some of the particulars of the inherited IRA wrong. There are two options:

* take at least the required minimum distribution starting in the tax year following the transfer, or

* draw down the entire account within 5 years

This applies to any inherited Ira that is not from your spouse, even if you are married. I.e., my inherited Ira (I'm married) is treated no differently from my sister's (she's not).

Distributions from inherited iras are taxed like ordinary income, no matter when they happen or by how much you take, unless you're unlucky enough to have not done your red, in which case there's a crazy penalty.

</comment><comment><USER32> Taxes generate government revenue as a side-effect of their purpose as a social engineering tool, not the other way around. Not sure why people get that backwards so often.

</comment><comment><USER33> Rather poor mathematics they did, and they should have consulted someone who could the maths a lot more accurately. Financial differences are just part of the way that singles are discriminated against - here is a longer list [http://www.nolo.com/legal-encyclopedia/marriage-rights- benef...](http://www.nolo.com/legal-encyclopedia/marriage-rights- benefits-30190.html)

</comment><comment><USER34> This post is sponsored by ...

</comment><comment><USER35> Perhaps they should find husbands then.</comment>


In MySQL, don't use "utf8", use "utf8mb4" (2016) - <AUTHOR> https://medium.com/@adamhooper/in-mysql-never-use-utf8-use-utf8mb4-11761243e434 <comment><USER2> Possibly my favourite thing about the rise of emoji is that they're not Basic Multilingual Plane, and so stupid hacks like MySQL's utf8 character set (I seriously don't know why anyone ever thought it was a good idea in 2002–2004) are now _obviously_ insufficient for full Unicode support, and enough people _care_ about them that adoption of this basic level of Unicode is driven, and so non-English speakers are inadvertently helped.

The next hurdle is to convince people that extended grapheme clusters are the smallest divisible unit, and that just like slicing at the byte level is insufficient if you're doing UTF-8, slicing at the code point level is insufficient. Basically, strings should just be treated as opaque data in almost all places.

<comment><USER2> While I'm contemplating why people might have thought utf8mb3 was wise in 2004, I'll ask a similar question that I'd love to know the answer to, of events from my early childhood: why did UTF-16 gain popularity? I get UCS-2 existing, but once it became evident it wasn't enough, why make UTF-16 and ruin Unicode with surrogate pairs (which still cause trouble today, leading to things like WTF-8 to make it possible for web browsers to abandon their UTF-16/UCS-2 mess in favour of almost-UTF-8)? UTF-8 was around by early 1993, while UTF-16 was developed several years later and seems fairly obviously the worst of both worlds—twice as large for normal text, ASCII-incompatible, and not even a fixed-width encoding, the _only thing_ it almost had over UTF-8. The only thing it had going for it was that it was _roughly_ compatible with UCS-2; but was UCS-2 _that_ popular at the time?

(Concerning UCS-2, hindsight says it should have been obvious 65,536 code points was going to be insufficient, but I'll overlook that as an easy mistake to make; that part is better documented than the rise of UTF-16.)

Possibly the most helpful description I have is from [https://en.wikipedia.org/wiki/UTF-16#History](https://en.wikipedia.org/wiki/UTF-16#History), but even that doesn't explain why it became _popular_. Why did Java adopt it, Windows, browsers, _& c._? _Why?_

<comment><USER3> With utf-8 you give up any hope of O(1) string operations. With utf-16 you can get O(1) string operations at a cost of doing them on code points rather than graphemes. If greater than 95% of the strings your language/program will ever see are going to be a single code point that trade off seems worth it.

I think a lot of people totally discount the enormous cost that Latin-1 users are paying for CJK (etc) support they don't use. Maybe it's the right call, but it isn't _obviously_ so.

Personally, at least for internal use, I like the idea of specialized implementations. At (immutable) string creation time decide whether to construct a Latin-1 string or a UTF-8 string (and possibly other fixed width encodings) depending on what code points are present. Expose the same set of operations (i.e. slicing on grapheme clusters) but with better performance characteristics where possible.

For storage at rest and especially communication with external programs I agree you probably should emit UTF-8.

<comment><USER4> Except that with utf-16 you still have to give up any hope of O(1) string operations, unless you don't care about accuracy. Only UTF-32 allows O(1) index based operations.

For example, 🧐 (aka face with monocle) needs 2 UTF-16 'characters', since the UTF code point is U+1F9D0, or, in UTF-8: F0 9F A7 90.

And this ignored the point that others have made about combining characters, such as  woman farmer Unicode: U+1F469 U+1F3FD U+200D U+1F33E, UTF-8: F0 9F 91 A9 F0 9F 8F BD E2 80 8D F0 9F 8C BE

That beast needs 7 UTF-16 or 15 UTF-8 "characters". I.e. 14 bytes vs 15 bytes. And this is still only one displayed character.

<comment> kyle-rb To clarify the woman farmer being 14 or 15 bytes: the example given is four different combined characters, and is additionally a "medium skin tone woman farmer".

A woman farmer requires the "woman" and "ear of rice" emoji, with a zero-width joiner character between them. To change the skin tone from the default yellow, a "medium skin tone" (type 4) modifier is added after the woman, but before the joiner.

So the sequence "U+1F469 U+1F3FD U+200D U+1F33E" represents "woman skin-tone-4 joiner ear-of-rice". And in the UTF-8 bytes, the first four bytes are "woman", the next four are "skin-tone-4", then three for "zero-width-joiner", and finally four for "ear-of-rice".

Emojipedia helpfully lists codepoints for each multi-character emoji: [https://emojipedia.org/female-farmer/](https://emojipedia.org/female-farmer/)

</comment></comment></comment></comment></comment><comment><USER5> Hi! Former Product Manager for MySQL Server here. I have a blog post on this here: [https://mysqlserverteam.com/mysql-8-0-when-to-use- utf8mb3-ov...](https://mysqlserverteam.com/mysql-8-0-when-to-use-utf8mb3-over- utf8mb4/)

The default for MySQL 8.0 (current GA) is utf8mb4. I also recommend reading this introduction post here: [http://mysqlserverteam.com/sushi-beer-an- introduction-of-utf...](http://mysqlserverteam.com/sushi-beer-an-introduction- of-utf8-support-in-mysql-8-0/)

<comment><USER6> > _An optimization was chosen to limit utf8 to 3 bytes_

You chose not to define the UNICODE_32BIT macro that was in the original source from 2002?

* [https://github.com/mysql/mysql-server/commit/55e0a9cb01af4b0...](https://github.com/mysql/mysql-server/commit/55e0a9cb01af4b01bc4e4395de9e4dd2a1b0cf23#diff-95de3baa9e399c689954d1b8442d0be8R1611)

<comment><USER5> The optimization was made at a different time in history. As I wrote in another comment here: while the decision is regrettable, because of a desire for backwards compatibility and simplified upgrade there wasn't an easy way out of it.

The utf8[mb4] support in MySQL 8.0 is much better than prior releases. The team worked really hard on eliminating the use cases for utf8mb3 (performance) so that "just use the default of utf8mb4" can work for everyone.

<comment><USER7> Is it really an optimization? I always assumed they picked 3 bytes to make sure a varchar(255) still would fit within the InnoDB field size limit of 768 bytes, so they could avoid/postpone having to fix InnoDB to support variable size fields.

<comment><USER5> This decision was made before InnoDB was the default.

While the performance differences are historical now, consider the case that because of fixed sized buffers, one query could switch from a temp table in memory to a temp table on disk. The profile of the query has effectively changed.

<comment><USER7> Yes, but did it happen before InnoDB was widely used?

</comment></comment></comment></comment></comment></comment><comment><USER8> Extremely important: If you use mysqldump, _make sure it 's also using utf8mb4_. There is a very high chance it defaults to utf8 and silently corrupts your data.

<comment><USER9> Oh my god, this is both terrifying and could one day prove to be the most valuable comment I've seen on HN.

I love MySQL, but the fact that they didn't make utf8mb4 the default for mysqldump (instead of utf8), when they created utf8mb4 for database use... is one of the most irresponsible and negligent pieces of engineering I've seen in a long time, considering the amount of data worldwide backed up with mysqldump.

The fact that a program designed solely to back up databases would default to silent corruption like this is mind-boggling. At least they've fixed this in the future for MySQL 8.0.

<comment><USER10> Imagine how many companies out there are relying on backups that are already corrupted...

is your company one of them?

<comment><USER11> This is an important reason why testing your backups is a critical part of backing up.

<comment><USER12> This is oft-repeated advice, but, in this context, it ends up being little more than a platitude.

Since the complaint here is of corruption that is _silent_ , the level of testing required to catch it would be extraordinary.

</comment></comment></comment></comment></comment><comment><USER13> This bit me hard many years ago in possibly the most frustrating bug I've encountered--frustrating because of the _stupidity_ of MySQL's implementation. I had a utf8 MySQL database that was created back before utf8mb4 existed--this is, back in the days when emojis were _just_ getting popular, but not quite popular enough to be on software keyboards; and when only a few people had smartphones and iPads, but not everyone.

People would post long-form content to my site that took a long time for them to compose, and maybe once a month, someone would email me to complain that their long post was mysteriously cut short. Inspecting the database showed that the content was being stored there cut off, but with no rhyme or reason. Nothing in the error logs. 95% of other posts went through fine regardless of length or complexity. I put in tons of debugging code at various levels of the app to see where the data was being mis-parsed or truncated. Nothing!

The bug persisted for _years_ without a hint. Finally, emojis became more popular, the bug started occurring more and more often, and MySQL released utf8mb4; and then it dawned on me: Occasionally, people would submit content that contained a Unicode emoji generated by their software keyboard, and MySQL would _silently truncate the emoji and all the data after it WITHOUT WARNING_ when storing it in a utf8 column!! Silently!

I was so mad. A bug that plagued users for years, so much time and effort spent trying to debug it, and it was because of a combination of MySQL's dumb engineering decision to not support full Unicode for something called "utf8" and then _silently truncating data without any warning_.

I don't know what the lesson is here. But I do know it made me really, really mad at MySQL when I found out what the problem was.

<comment><USER14> I think the lesson is "don't silently fail," and in that regard mysql has failed at learning that lesson over and over again to the point where the lesson is now, "don't use mysql" because what else can you do when dealing with such shitty software? This is far, far from the only stupid bug like this. Use mysql only if you don't care about preserving data. Period. There are many valid use cases that don't care about preserving data 100%, apparently most companies, so it's not a huge issue in reality. Hopefully the data that deals with monetary transactions won't get corrupted, but when it does, one cannot complain if they used mysql. It's that simple.

<comment><USER15> does that affect MariaDB as well? That would only leave people to PostgreSQL or NoSQL Databases like MongoDB AFAIK. I've never been a fan of MySQL, but MariaDB always seemed to me like the spark of hope that was left in there.

<comment><USER14> Yes because it's built on the same codebase with the same design decisions and bugs. Maybe in the future it will diverge enough and fix such issues although compatibility with mysql might be affected.

</comment></comment></comment></comment><comment><USER16> Friend of mine just recounted a story of when this bug killed all their MySql instances across an entire enterprise installation because a user sent an email with the hamster face emoji in the title.

<comment><USER17> I worked at large company where an emoji or other 4-byte UTF character in a commit message would take down multiple systems simultaneously, including JIRA and various internal auditing and pipeline monitoring tools. It happened surprisingly rarely considering the lack of safeguard against the issue.

<comment><USER18> This happened to us too. We first noticed it in Bamboo with a failed build job. It's been a long time since I installed Bamboo, but if I recall correctly the installer adds its own schemata.

</comment></comment></comment><comment><USER19> This is a fascinating tale. But the #1 takeaway by the author is dangerous: "Database systems have subtle bugs and oddities, and you can avoid a lot of bugs by avoiding database systems."

This is correct as far as it goes, but it's poor advice. You may as well say "Software has subtle bugs and oddities, and you can avoid a lot of bugs by avoiding software." True! But not helpful! If you don't need a relational database, then yes, don't use one. But there's nothing specific about databases as a category that deserves a special callout. You can also avoid a lot of bugs by avoiding TLS, containers, threads, coroutines, blocking calls, asynchronous calls, networks, filesystems, operating systems, and computers.

<comment><USER20> Dangerous? How do you figure?

Many people assume a DB is the only way to store data. Now that's dangerous.

<comment><USER21> Because filesystems don't contain oddities...

<comment><USER20> All storage systems have trade offs. What else is new?

</comment></comment></comment></comment><comment><USER22> I've "bookmarked" this: [https://mathiasbynens.be/notes/mysql- utf8mb4](https://mathiasbynens.be/notes/mysql-utf8mb4)

It digs a little bit deeper on the MySQL side (and it's from 2012 btw)

</comment><comment><USER23> > If you need a database, don't use MySQL or MariaDB. Use PostgreSQL.

This is stupid. There are pros and cons to every database. For example, MySQL allows you to set a trigger on an op, PostgreSQL requires you to write a function first.

<comment><USER24> > This is stupid.

Talk about stupid, run this query on both Mysql and Postgres:

select 0 = 'banana';

Make your own conclusion.

<comment><USER25>
      mysql> select 0 = 'banana';
      +</comment></comment></comment><comment></comment><comment>--+
      | 0 = 'banana' |
      +</comment><comment></comment><comment>--+
      |            1 |
      +</comment><comment></comment><comment>--+
      1 row in set, 1 warning (0.00 sec)

vs

      pg# select 0 = 'banana';
      ERROR:  invalid input syntax for integer: "banana"
      LINE 1: select 0 = 'banana';

<comment><USER12> My conclusion (not just based on this example), is that MySQL favors (initial) ease [1], whereas PostgreSQL favors correctness [2].

To suggest the former approach is "stupid" is to fail to explain how it became so wildly popular. I allege that it is actually brilliant.. marketing.

MySQL marketed itself to developers by being not just free, but easy to work with. Need a database? Want to learn SQL? We won't bore you or slow you down with Codd and those pesky rules maaaan. It'll just work!

For the vast majority of use cases, it did exactly that.

Meanwhile, Postgres was esssentially sending the stodgy, old-fashioned message that databases are a hard problem that require careful up-front consideration so that one doesn't run into problems down the road, be they scale/performance or more severe like (even non-catastrophic) data loss.

That this message was, and still is, correct, just isn't very compelling in a rapid-protoyping fail-fast world. Unfortunately for those of us whose job it is to deal with the eventual consequences, it's too late by the time we're brought in [3].

I think we've seen a similar effect with many of the "NoSQL" datastores, as well. They gain initial popularity due to being easy, lightweight, and lightnight fast, but, as they mature and gain real-world use, we see articles that are shocked (shocked!) that there is data loss going on in this establishment and that, yes, if you need certain tedious features (like data integrity) from that stodgy old database world, you'll have to sacrifice that lightning fast performance.

[1] aka flexibility [2] aka standards adherence or even pedantry [3] though I've never quite understood the reasoning of why it would be so impractical to move RDBMSes when there's so often an ORM and no MySQL-specific features in use

</comment></comment><comment><USER26> Wait, isn't 4 bytes per character _also_ not enough to store UTF8? Can't each character be up to 8 bytes long, because the number of leading 1s in the first byte determines the length of the character?

<comment> ainar-g According to the Wiki, the original UTF-8 proposal used up to 6 bytes.[1] But the Unicode standards people decided that 21 bit should be enough for everyone:

>Since the restriction of the Unicode code-space to 21-bit values in 2003, UTF-8 is defined to encode code points in one to four bytes, depending on the number of significant bits in the numerical value of the code point.

So, if they ever decide to use those extra two bytes, it will probably not be called UTF-8. Perhaps something like "UTF-8-MB-6".

[1] [https://en.wikipedia.org/wiki/UTF-8#History](https://en.wikipedia.org/wiki/UTF-8#History)

</comment></comment><comment><USER27> "An optimization was chosen to limit utf8 to 3 bytes, enough to handle almost all modern languages."

I can't for the life of me imagine how, when discussing this in a room full of competent developers, everyone just went "great idea, lets do this". Just adds to the long list of questionable MySQL engineering decisions.

<comment><USER7> I am pretty sure it was not because of any optimization but that the real reason was to make sure a VARCHAR(255) would still fit within the maximum field size of InnoDB (768 bytes) at the time.

Since then MySQL has added ROW_FORMAT=DYNAMIC to InnoDB which allows for larger values, but that probably required major changes to InnoDB.

<comment><USER27> There is usually a good reason for doing these kind of things. But then _don 't call it UTF8 encoding_! It doesn't do that. It stores the most popular characters out of a larger address space. Call it UTF8-MB3 maybe from the start and let the user decide if having varchar(255) is worth the tradeoff. Thats the trouble with MySQL: doing silently the wrong thing, and thus violating the principle of least surprise. There is software where this might be ok, but a database is not that kind of software.

<comment><USER28> In the case of MySQL (especially MySQL in 2003) bad design and silly behavior isn't much of a surprise though :)

</comment></comment></comment></comment><comment><USER22> Side note: It's not enough to change the encoding of the database, you need to make sure that all involved parties use the same encoding (or convert the charset at the interfaces).

For instance in a Laravel app I had to set the charset in the database configuration file "app/config/database.php".

</comment><comment><USER29> > I'll make a sweeping statement here: all MySQL and MariaDB users who are > currently using "utf8" should actually use "utf8mb4". Nobody should ever use > "utf8".

I completely agree with this sentiment, although I recall being bitten by it in indexes. The article goes on to talk about how big a CHAR(1) is if its utf8 vs utf8mb4. Well, the same applies to varchars and so a varchar(64) is potentially requiring 64, 192 or 384 bytes, depending on the charset. This can bite you because the MySQL query planner limits the longest prefix used for index scans to iirc 767 or so bytes. So I migrated some columns from utf8 to utf8mb4 and suddenly my compound indices stopped being used because the varchar contents could legally exceed that maximum. Something like that.

</comment><comment><USER2> One troublesome thing about utf8mb4: if you have a VARCHAR( _n_ ) column, this means 4 _n_ bytes are required; this doesn't mix particularly well with indexes, as you can only index columns of up to 767 bytes; VARCHAR(192) is thus 768 bytes, and too long to be indexed—so you're limited to VARCHAR(191) or less.

This leads to things like django-celery flat-out not working on utf8mb4 without a (history-rewriting) patch, because it had a VARCHAR(255) primary key: [https://github.com/celery/django- celery/issues/259](https://github.com/celery/django-celery/issues/259).

<comment><USER30> then again, indexes on VARCHAR() can only really be used for equality and start matches.

Now I'm not saying it's impossible, but I have a feeling you're not likely going to do a lot of `where string_column =… ` or `where string_column like '…%'` where … is 192 characters in length.

If you need to do substring search or full text search, a traditional index won't help you anyways.

<comment><USER2> Yeah, string primary keys are the only place I expect people to actually hit this, as seen in the django-celery case.

</comment></comment></comment><comment><USER31> Given that the article says that everyone should use utf8mb4, then why don't/haven't they just fixed it? Should be easy enough, and probably safe, too.

<comment><USER22> They have. It's the default in MySQL 8.

<comment><USER31> Sorry, should have bern more clear: why didn't they fix the bug in utf8 so that it is correct (and would do what utf8mb4 does now)? It's just that the obvious choice of 'utf8' has been plain wrong for a long time.

<comment><USER32> from the article:

>Once MySQL published this invalid character set, it could never fix it: that would force every user to rebuild every database.

</comment></comment></comment></comment><comment><USER33> It is worth mentioning that if you're stuck with InnoDB + COMPACT + utf8mb4 then you should be using VARCHAR(191) instead of VARCHAR(255) for unique columns.

[https://dev.mysql.com/doc/refman/5.7/en/innodb-row-format- an...](https://dev.mysql.com/doc/refman/5.7/en/innodb-row-format- antelope.html)

</comment><comment><USER34> Currently leading a massive thorny project to convert all of our databases to utf8mb4. Definitely heed this warning.

</comment><comment><USER35> I use utf8 for "normal" field like name, address, etc.. (don't want smiley as first name). And use utf8mb4 for comment for example.

But I need filter/validate each inputs (and refuse when there is 4 bytes characters).

<comment><USER36> There are more characters outside BMP than just emoji.

</comment></comment><comment><USER37> In case you want to convert your MySQL database tables from utf8 to utf8mb4 please remember that each character will now take 4, not 3 bytes. This means you can easily run out of limit for a row length (65536 bytes) if you have many string columns and your indexes will grow. Also, if a column is a part of a foreign key reference you might have to remove the foreign key first, upgrade columns on both sides and add the foreign key back.

So converting an existing database might be not as easy as it seems before.

</comment><comment><USER38> The article mentions it, but one of the massive frustrations with this issue is the huge amount of misinformation surrounding it (at least back in 2013), with many well-intended users on StackOverflow and the MySQL forums giving the exactly wrong advice on collation. Naming things, and not getting confused by bad names, is damned hard. This issue led me to quit MySQL for good, I can't think of a more trivial issue that caused me such confusion and frustration as a software engineer.

</comment><comment><USER39> Good reminder. I did read a well hidden article many years ago which highly recommended this. I believe I was hitting an obscure, arcane bug like the OP mentioned in the article, and after much digging managed to find this fix.

Since then, I _always_ set every new MySQL database (and even double check the tables) to be 'utf8mb4' even long after the original lessons and pain have been forgotten.

</comment><comment><USER40> > _" Once MySQL published this invalid character set, it could never fix it: > that would force every user to rebuild every database. MySQL finally > released UTF-8 support in 2010, with a different name: "utf8mb4"."_

Had MySQL defined UTF-8 as up to 6 bytes initially, would they later force users to rebuilt their databases when UTF-8 was redefined to only 4 bytes?

</comment><comment><USER41> > X have subtle bugs and oddities, and you can avoid a lot of bugs by avoiding > X.

That doesn't sound like a useful advice

</comment><comment><USER42> Dear database developers, please don't get hung up on string lengths.

I'd be very happy to ask the DB for (say) a UTF-8 string of up-to 80 bytes. That means I could store 80 ASCII characters, 40 two-byte characters, 20 four- byte characters or some mixture as I wish.

<comment><USER7> At least PostgreSQL does not care about string length, other than as required by the SQL standard (e.g. it enforces varchar(20) by counting the number of code points). The maximum size of a string in PostgreSQL is 1 GB.

</comment></comment><comment><USER43> It's a code smell when what is obviously and intuitively stated, is in fact, incorrect.

</comment><comment><USER44> Oh, I love these kind of Unicode bugs. Also, please don't use utf16 in C# - although it advertises as using utf16, all of it's built-in string processing actually works on code units, not Unicode code points and breaks down on surrogate pairs.

Anyway, each time you start a new project that is supposed to work correctly with multi-language data, please set up evil strings test suite as early as you can and do not assume that any of the 3rd party software that you're using won't break down.

<comment><USER45> Previous discussion on HN for 'Naughty Strings', was certainly an entertaining and eye opening read...

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

</comment></comment><comment><USER46> Anyone more knowledgeable than me care to explain the difference between utf8mb4_unicode_520_ci and utf8mb4_unicode_ci?

<comment><USER47> Different versions of the Unicode collation algorithm, which determines how strings are sorted. 520 is Version 5.2.0, without the number it's 4.0.0 by default

[https://dev.mysql.com/doc/refman/5.6/en/charset-collation- na...](https://dev.mysql.com/doc/refman/5.6/en/charset-collation-names.html)

<comment><USER46> Thanks, but what are the implications, if any, of using either one?

</comment></comment></comment><comment><USER48> Instead of MySQL, use PostgreSQL.

</comment><comment><USER49> > In MySQL, never use "utf8". Use "utf8mb4".

I thought you shouldn't use MySQL in the first place.

</comment><comment><USER50> Counterpoint: emojis are bad and should be discouraged

<comment><USER5> I feel just the opposite: emojis are a lot more expressive than text and more universal in language than en-us.

<comment><USER51> What about winking emojis? I feel there's a lot more ambiguity/nuance with them, which can be a good thing, but can also express something you may or may not intend to.</comment></comment></comment>


Revisiting the spectacular failure that was the Bill Gates deposition - <AUTHOR> https://arstechnica.com/?p=1704751 <comment><USER2> These days, it's easy to forget how downright evil Gates and Microsoft were back in the day.</comment>


LogMeIn and DocuSign investigate email breach - <AUTHOR> http://krebsonsecurity.com/2012/12/logmein-docusign-investigate-breach-claims/

<comment><AUTHOR> I have seen something similar before, and let a comment with a theory on what has happen here[0].

There is an SQL statement with a user provided LIKE comparator value that is returning email adress which isn't being filtered properly. The attackers take advantage of this by running a set of dictionary words against it with %, for eg. logmein% will return all emails containing 'logmein'

[0] [http://krebsonsecurity.com/2012/12/logmein-docusign- investig...](http://krebsonsecurity.com/2012/12/logmein-docusign-investigate- breach-claims/comment-page-1/#comment-134384)</comment>


Programming with a Differentiable Forth Interpreter (2016) - <AUTHOR> http://arxiv.org/abs/1605.06640v3 <comment><USER2> Discussion from 2016: [https://news.ycombinator.com/item?id=11766092](https://news.ycombinator.com/item?id=11766092)

I also found this article on differentiable programming: [https://pseudoprofound.wordpress.com/2016/08/03/differentiab...](https://pseudoprofound.wordpress.com/2016/08/03/differentiable- programming/) but a foundational TL;DR would be highly appreciated.

<comment><USER3> I think Richard Fateman's paper on the subject is a good introduction: [https://people.eecs.berkeley.edu/~fateman/papers/ADIL.pdf](https://people.eecs.berkeley.edu/~fateman/papers/ADIL.pdf)

</comment></comment><comment><USER4> > end-to-end differentiable interpreter for the programming language Forth > which enables programmers to write program sketches with slots that can be > filled with behaviour trained from program input-output data. We can > optimise this behaviour directly through gradient descent techniques on > user-specified objectives

Neat. What sort of things have been achieved with machine-learning over algorithms, though? I've seen the topic crop up now and then, but I couldn't name any real successes.

<comment><USER5> I haven't read this paper, but the way deep learning is evolving is becoming more like general-purpose programming. People have even started calling it "differentiable programming". The basic driving force is that the neural network architectures people are using are becoming more and more complex, employing state and dynamically changing structures. To express this deep learning frameworks are becoming like general-purpose languages with the constraint that everything has to be differentiable for optimisation to work. So I don't think the driving force is that "normal" programs will have machine learned components, but that machine learning is becoming more like programming.

<comment><USER6> ... and will soon be seen as (and actually be!) very mundane and not really AI at all, although a very useful tool. Just like optimizing compilers.

<comment><USER7> It still does the exact same thing as it did 10 years ago. Whether or not it is seen as OR is AI is a different topic. Anything that becomes more widely understood seems mundane and less sexy than when it is an emerging field.

<comment><USER8> On that different topic, real progress starts the moment it is not seen as AI.

</comment></comment></comment></comment></comment><comment><USER9> So does this combination procedural language + neural net architecture allow random modification of FORTH words or does it only allow random use of pre- defined subroutines with random values for parameters?

Random modification / creation of random algorithms sounds like Doug Lenat's Eurisko. The use of random values for parameters in a pre-defined subroutine sounds like a contraint propagation language like Prolog. I guess the random use of a pre-defined set of subroutines is similar to a system that does load balancing for choice between various algorithms instead of different machines.

<comment><USER10> It manipulates "sketches" which seem to act as a template and search strategy. E.g. for the word algebra problem, the neural net is told to look at the top 4 stack elements and figure out how to arrange a pair of arithmetic operations (the sentence is first "parsed" by a RNN.)</comment></comment>


Does My Rails App Need a Service Layer? - <AUTHOR> http://blog.carbonfive.com/2012/01/10/does-my-rails-app-need-a-service-layer/

<comment><USER2> I love it! As rails matures and is used on bigger and bigger projects, it starts to look more and more like Java. It used to be all about rapid development... but now we're all talking about performance, and threads, and service layers. Thank god node.js is here to remind us that we really don't need any of that crap.

</comment><comment><USER3> Jared suggests using services to translate into different protocols. I see a further use for services to translate models into different representations on the same protocol in order to support a versions API. Let a service handle mapping outdated API payloads to the latest version of the domain model.</comment>


AXR: A better(?) alternative to HTML+CSS - <AUTHOR> http://axr.vg/ <comment><USER2> I don't understand why they are implementing the prototype in C++. If you built it in JavaScript, any modern browser could load their alternative markup and render it through some sort of fallback (I would expect HTML5+CSS+Canvas+SVG all put together provide enough functionality to render content expressed in their new language(s)).

Building it in C++ basically guarantees that nobody will be able to use it, ever, because it provides no support for older browsers and no support for older HTML-oriented technology like search engine spiders.

<comment><USER3> It's designed as a library that browsers would use to render the content, as far as I can tell. So C++ is fairly sensible in that respect.

Whether even one of the major browsers will support it is the question, and what the pages will look like in other browsers (if there's any fallback) remains to be seen...

</comment></comment><comment><USER4> Worse is better.

Sorry, but HTML isn't going anywhere. XML had its chance — full support from W3C and implementations in all-but-one browsers _for a decade now_. text/html parsers survived that.

I don't think you can convince all browser vendors to bet on XML again. They all opposed XHTML2. W3C tried to push XHTML2 without them and ended up making HTML even stronger.

XML with vector shapes? We've got SVG. It may not be perfect, but has tools and implementations.

Easier CSS layouts? Flex box, grids and calc() are around the corner. They'll be usable sooner than HSS, and kill the project by being good enough.

<comment><USER5> You're right: HTML is going to stay with us for a long, long time. This is not about eliminating it, but to try something new as an alternative.

It's not XML with vector shapes, that's exactly what SVG _is_. Vector shapes would live all inside HSS, where you could reuse them, style them, give them flexible sizes, apply effects, etc...

Once flexbox, grids and calc come out as official specs, you'll still have to wait until all browsers implements them, and then wait again until enough users update. You'll probably have to do an old-style layout as well anyway, because there are always users with older browsers out there, and it's not as easy as with rounded corners, where if they aren't there it doesn't matter. This would break your entire page...

<comment><USER6> _Once flexbox, grids and calc come out as official specs, you'll still have to wait until all browsers implements them, and then wait again until enough users update_

How would the situation be any different for AXR?

<comment><USER5> The plan is to make the rendering engine an auto-updateable library, that's independent of the browser's release schedule. Thus, users would stay current faster.

On the other hand, there will be a versioning system, so that authors can specify what version of the technology they are targeting. So if the spec changes, compatibility modules can be created akin to how Adobe apps open documents differently if they are CS3 or CS5 documents, interpreting them according to what version they are.

Usually, layers can be built with new features, where only the very basic aspects of your design require a certain feature set, while others can be optional. In some scenarios, the user will have an outdated system and the author has REQUIRED a higher version than what is installed. Then a built-in prompt to update could be displayed, maybe with an option to view anyways, with the knowledge that it may render incorrectly.

Long story short, there are many things that can be done, and we certainly will learn a lot along the way, but I think we should definitely try.

<comment><USER7> This sounds like something we already have. I don't want this to sound confrontational, since I know the F-word is viewed as kind of "dirty" around here, but how is what you're proposing substantially different from Flash?

<comment><USER5> Well for starters its open source instead of proprietary. I think that already deserves some respect on its own.

Then, this is based on doing websites in the web standards spirit of using plain-text files, where multiple components are linked together, and having the semantic content (XML) separated from the presentation (HSS).

I mean, we like the _concept_ of HTML+CSS, but we would like to see many of its flaws and shortcomings corrected.

</comment></comment></comment></comment></comment></comment><comment><USER8> Too many of the comments here are implying that "It's too hard, there's obstacles in the way, so don't bother". Which is pretty disappointing.

To a large extent, I agree with that sentiment. There may be obstacles, more human than technical, but under no circumstances should that ever be an excuse for not even trying. All the best, and I like the cut of your jib.

</comment><comment><USER9> Show me the CODE! Where is it???

If you are trying to revolutionize and disrupt existing languages/syntaxes, show how yours is better! Side-by-side on the front page is best. Look at CoffeeScript's site.

<comment><USER10> The presentation on the front page has comparisons.

<comment><USER9> I had to scroll 12 slides until I reached the first snippet.

</comment></comment></comment><comment><USER11> I was expecting something different. I thought this was going to contain solutions for building web apps at scale, but it's basically a way to build plain old websites with a somewhat nicer and more maintainable syntax.

Some things that I want to see solutions for:

* Implementing richer controls that can behave as if they are native to the platform (e.g. building a better date picker that is fully encapsulated from the perspective of the developer)

* Dealing with styling at scale (tens of thousands of lines, up to a dozen levels of element nesting)

* Encapsulating application modules so they are incapable of conflicting with other application modules (in structure, behavior and styling), and can have a separate lifecycle from the page they are loaded into.

To me those are the real problems in building web apps at scale, and I was expecting to see solutions for these.

<comment><USER5> You're rising some interesting questions. Mind posing them on the mailing list? That would be awesome :D Cheers.

</comment></comment><comment><USER12> I have to have Flash installed to see the slide deck that actually shows code samples? So much for "the web done right".

</comment><comment><USER13> Won't we have the same problem once it's implemented in browsers? They implement different things, in different ways. And XML does induce a lot of overhead compared to other ways to share data. I'm not against changing the way we code, but it has to be well thought out.

<comment><USER14> _Won't we have the same problem once it's implemented in browsers?_

Indeed. This faces an uphill battle to get critical mass and once browser makers decide to support it natively there's going to be pressure to roll it into the standards process.

</comment></comment><comment><USER15> I don't think AXR is the solution to rendering engines not keeping the same pace. It's hard to have competition and at the same time wish I didn't have to check my CSS in Trident, Gecko, Presto and Webkit.

</comment><comment><USER16> I don't think XML is any better than HTML for presentation. In fact, HAML is way better, and much more powerful. In the same way I don't see why to use HSS when we have SASS/SCSS, Jade, Less...

<comment><AUTHOR> These abstract metalanguages are still somewhat limited by the underlying base of HTML and CSS. Some things simply can't be accomplished with CSS, no matter how many SASS macros you write (e.g. reparent an element), or you'll just end up with lot of code to do tasks which would be simple with HSS.

I believe that point of AXR is to replace this underlying base, with something more suitable for web applications. You could still use a metalanguage on top of it (maybe with some tweaking) - you can write XML using HAML anyway.

<comment><USER11> What do you mean by reparenting an element if not the nesting example given on the SASS homepage?

<comment><AUTHOR> In presentation - [http://www.slideshare.net/veosotano/axr-presentation- betabee...](http://www.slideshare.net/veosotano/axr-presentation-betabeers- english) \- slides 12 and 13, including new elements creation (<http://axr.vg/spec/chapter/55>). Didn't find anything on parent property in spec, though. Nesting is also planned (slide 15)

<comment><USER5> Sorry about that. It's not fully fleshed out yet. Are you interested in helping us figure out how to make the reparenting syntax as nice as possible? If so, I think the mailing list would be the best place for that... :)

</comment></comment></comment></comment></comment><comment><USER17> _The terms to use and redistribute all source code for the AXR project WILL CHANGE in the future, since it will include clauses not included in any of the available free software licenses, mostly in aspects that will ensure the integrity of AXR as a web publishing platform._

This is worrying. What exactly are you expecting to put in such clauses? Anything more restrictive than Apache v2 (like the current license, GPL) is 100% sure to rule out inclusion in some browsers.

<comment><USER5> What I wanted to put in the final license was something along the lines of "an implementation of the specification is only granted the permission to use the technology if at the time of being released (out of beta) it is absolutely compliant with the specification, obtaining a 100% score on all the tests released by the official AXR community", to be able to ensure that we don't end up in the same situation as now, in case other implementations appear.

This obviously needs to be studied and discussed to great extent, but I put the warning in the current licensing text to not have anyone think that it will be the final license...

What do you think, would you agree with that idea? If not, why not?

<comment><USER17> I didn't understand: that's the copyright license of the code, or a license of the spec?

If it's the license of the code, then it's not GPL compatible and hence Firefox can't use it, since they tri-license GPL, LGPL and MPL.

</comment></comment></comment><comment><USER5> Hi there! My name is Miro Keller, and I'm the founder of AXR, so I'll probably be the best person to answer any questions you guys may have. So feel free to ask me anything about this project :)

I'll try to answer all questions posed here, step by step:

@shimonamit: The code is not the only part that's important here, it's just one piece of the puzzle. So how would you go about to determine what part of the code to show, and at the same time try to convey the general idea to the visitors, without overwhelming them with too much information at once?

If you click on the "enter the site" button you'll see the spec, where there's plenty of code for you to read through :)

@ahrens: One of the most important points about the project it's that it would be the _same_ library used by the browsers, they wouldn't reimplement it. And to account for syntax variations in future versions, there is a versioning system, where the author of the document declares which one it is targeting. Thus, the rendering engine will know what the author actually wanted to say and interpret it accordingly.

What other ways of sharing data do you mean? We are open to suggestions about what technologies to use, we just want it to be great. Keep in mind that there are a couple of requirements, all of which are achieved with XML, such as:

\- It needs a way to be semantic, so that common things on the internet must be representable, such as products, events, flight reservations, etc. XML solves this with namespaces. \- It needs to be able to provide a way to show documents written in that language in current browsers using a plug-in. XML solves that with XSLT (there will be a standard .xls file for easy backwards compatibility). \- It should be able to be just uploaded on an FTP server by the average author, just as HTML, without installing server-side software or messing around with settings. \- It should be easy to write for authors.

So, again, we are open for suggestions, but keep in mind those requirements. If any other one you know of fits the bill, we would love to hear about it!

@drKarl You're missing the point. XML is used to represent the _structure of your data_ , not the presentation. That's what HSS is for.

On the other hand, with all those other languages you mentioned you have the problem that you'll always end with plain old CSS. Therefore you may get an easier syntax, but you still have all the problems associated with CSS: browser fragmentation, static syntax (you can't do "100%-50px" or "ref(height of myOtherElement)" ), no vector shapes support in the language itself (SVG doesn't count), etc.

@lovskogen Well AXR tries to be an alternative platform to HTML+CSS, not to replace it. It would still face much competition from that and Flash, Silverlight, or any other RIA out there....

The proposed solution is that the implementation is provided by the project itself, so that the rendering engine would be always the same. They could still differentiate themselves by providing unique UI, history management, social media integration, developer tools, etc. The part that we want to be the same, and only that part, would be the same. Of course, there is more to it than this, such as auto updating the engine independently from the browser, versioning system for stylesheets, etc, but that would be too in depth to discuss it here :)

@kevingadd Basically the main reason we opted for C++ was performance and cross-platform compatibility. Doing it in JavaScript would make it slow as hell. But hey, we would love to see more ideas of how this could be done. At the end of the day this is just a prototype, it is meant to explore ideas and see if and how this can be done at all.

You're wrong about nobody able to use it, since one of the main goals of this project is to support older browsers to increase chances of adoption. That's why there is a step-gap measure in the plan to create a wrapper that will use the library as a browser plug-in, so that it can be installed anywhere where there is a NPAPI or ActiveX interface (in IE). We already spotted a framework that will assist us in this (<http://www.firebreath.org>), so hopefully this won't be too difficult :)

Cheers, Miro

<comment><USER2> Performance doesn't matter if nobody can use it, and right now nobody can use it. By the time you have a working C++ implementation, for all you know v8 and SpiderMonkey's optimizers will be generating code just as fast as your C++. You're allowing an engineer's natural love of premature optimization to distract you from actually getting your product in front of people.

C++ is also _less_ cross-platform in this sense because to support multiple platforms, you will have to support compilation across target platforms and handle the variety of plugin APIs available for those platforms. And on iOS, your stuff won't work at all because it's Javascript or the highway if you want to run in Safari. (I guess you could ship your own browser on the App Store, but I suspect you'd run into rule hassles.) Maybe you could use Native Client, but in that case you will need to ship native client binaries for each CPU architecture and you'll only work inside Chrome.

Attempting to entirely supplant the browser's rendering engine with yours in a plugin is also a hopelessly shortsighted move. You'll be throwing out all the hardware acceleration and advanced layout logic provided by modern browsers. Just rendering text is complex enough to require multiple full-time salaried engineers, and you will have to bear that burden if you will ever be compatible with HTML/CSS, because international text is _important_.

Build a prototype using JavaScript, HTML, and Canvas/SVG where needed. Put it in front of people. Let web designers and programmers play with it. If they can play with it, they'll find reasons to love it. Once you have web designers and programmers who love _your actual product_ , you have a path to success.

<comment><USER18> _By the time you have a working C++ implementation, for all you know v8 and SpiderMonkey's optimizers will be generating code just as fast as your C++._

I dont think that's going to happen anytime soon.

But I agree that JavaScript is the way to go with this. The prize is not that high to justify such a steep adoption curve. I mean "make A as wide as B is high" can be accomplished in javascript today.

<comment><USER5> The goals of the project are way beyond just making "A as wide as B is high". That is just a drop in the ocean. Once we do effects (such as shadows, blur, noise, etc) and more advanced processing we'll need as much performance as we can.

<comment><USER18> I think you need better marketing, then. I glanced over the page and didn't see anything that "wowed" me. I think that's needed to justify the effort.

<comment><USER5> The people that I usually see getting wowed are web designers and devs, that know the pains of dealing with all those issues that this project is trying to solve. I don't know your background, but if you don't do CSS you probably don't know or care about all the troubles that one has to go through to get your site working correctly across all browsers, laying out your page (most apparent in fluid designs, or with dynamic content from a database), etc.

And again, we would love to hear about how we can market ourselves better, we are all ears!

</comment></comment></comment></comment></comment></comment><comment><USER19> If you are going to start from scratch, why would you ever use XML? XML violates so many things we know to be good, including the essential lisp idea of 'data is code' (which json does OK), not to mention it's ugly, hard to read, and makes for arbitrary patterns.

<comment><USER20> The one thing XML is great it, as the name suggests, is _markup_. And I am in favor of marked up text continuing as the basic model for content in any next generation web platform.

</comment></comment><comment><USER21> >HSS is a language based on CSS, but offers many more advanced features, such as object orientation, rule nesting, expressions, references to other objects, modularization (code reuse), etc.

Ew. This is an advertisement? Elegance is usually achieved when you hit a maximum of capabilities with a minimum of explicitly defined features. The last thing you want is so many different constructs that when someone reads your code they have to keep a reference manual handy.

Granted, I haven't worked my way through the spec, but maybe there's a better way to phrase that sentence that doesn't evoke memories of C++.

<comment><USER5> Suggestions on how to improve the phrasing of the website are always welcome :D

I'd love to hear if, once you've read through the spec you still feel that the features are perceivably as complex as C++... I think they feel very naturally into the language, but then again, I designed it, so your mileage may vary ;)

</comment></comment><comment><USER22> On an emotional level, XML is annoying.

XML is strict and unforgiving - great for validation, tools, and stuffing into SOAP envelopes. OTOH, for all of HTML's warts, it is flexible and forgiving to humans. Great developers and designers want to be happy working with their creations, and WYSIWYG tools often do not fit the process. So when you are forced to work with markup by hand, the perceived friendliness and ease of the markup language is significant.

In the end, to each their own. But programming languages are a popularity contest. Especially new ones.

</comment><comment><USER23> Okay. Assuming I liked it and it really works. This is going to make websites, no? How is this going to display on the browsers that people are using? Is my site going to be consistent across them?

<comment><USER24> As they say on their front page: "The part of the various browsers we want to NOT be different, the rendering engine, would be shared among all of the browsers".

</comment></comment><comment><USER25> Have you guys looked into Qt's QML? It is already there and addresses the same problems that you are trying to. All it needs is some more publicity.

<comment><USER5> I've looked at it and it seems to share goals with AXR, but how good is it for semantics, accessibility and backwards-compatibility? Those are quite essential requirements.

</comment></comment><comment><USER26> in my django stack, i already have shpaml+sass+templating. this by itself, already fulfills all my html+css needs, and it makes it retardedly easy to work with. why would i need to change something that is already working?

<comment><USER5> So can you do "myElement { alignY: 50% }" or something like that to automatically center vertically in your browser?

Or can you do "100% - ref(width of sideColumns)" to create two fixed-width and one fluid column in the middle?

Or can you rely on having exactly the same interpretation of your code across all browsers?

...

I guess you are looking at just a limited subset of what AXR is, mainly the syntax features that are similar to SASS and the like, while ignoring all the other problems it solves.

Of course we can do websites now, but no one says it's easy. Just think at all the productivity gains and improved user experience... !

<comment><USER27> Why do you think AXR would have the same interpretation across all browsers? Dont you think somone _cough_ will make their own implementation that fucks up the rendering/layouting just for the heck of it? _cough_

<comment><USER5> The reason is because that's one of the main pieces of the project. Providing a library that browsers can USE, not IMPLEMENT.

Why would anyone do that? That's WAY too much work just for fucking something up just for the heck of it.

<comment><USER27> > Why would anyone do that?

Business model of proprietary software, return on investment on lock-in of customers.

</comment></comment></comment></comment></comment><comment><USER28> The slide deck is flash... Mmmm... Are u being serious when u say "web done right"?...

</comment><comment><USER29> Wait - we're going back to XML again?

</comment><comment><USER30> I'm looking forward to seeing where this goes. It may not be the tool that replaces the current html/css set, it doesn't even have any mention of how javascript fits in, but its very encouraging to see that it is getting worked on. We do need to replace them, and playing with things like axr is a start.

Our current web programming stack is a depressing, ugly hacked together kludge with painfully limited capabilities, even how HTTP fits in needs to be examined, it has its place but it can't remain the only option. Websockets are a solution to a problem that doesn't have to exist. I have nothing against the fact that we're wedging more and more into technology that it was never designed for, but the seams have been showing for quite some time how.

<comment><USER5> It does indeed use JavaScript. Sorry about not being more clear about it in the spec, but that's a part we're still working on.

It will feature a completely new DOM, integrating the properties of the HSS side and the JS ones all into one. Functions and code will be executed by setting something like this:

myElement

{

       behavior: @click {

          action: @javascript {"

             //your code goes here

          "}

       };

}

But that's not the usual way one would use this, instead one would do:

//define the click handler

@click myClickHandler {

       action: @javascript {"

          //your code goes here

       "}

}

//assign the handler to your object

myElement { behavior: myClickHandler; }

This way, you can see how it will be reusable, and your javascript can be assigned inside of any preset that you may create and apply, instead of selecting the element again from inside javascript in another file.</comment></comment>