Pixar's Universal Scene Description - <AUTHOR> http://graphics.pixar.com/usd/ <comment><USER3> Proprietary 3d formats is still a pretty big problem, anything that helps that is good.

COLLADA tried to help that but formats like FBX have won out even though they are proprietary, bloated, binary and not well documented because one company (Autodesk) has no desire to improve interoperability since they own all 3d platforms essentially.

There really should be more standardization in 3d by now, this probably came out of necessity for Pixar. This takes it a bit further with full scene descriptions rather than just individual assets.

I have a feeling WebGL will do the most for pushing standardizing of 3d formats/objects/scenes over time as there is little efforts elsewhere. I actually hope with Unity, as big as they are, would help this front as they are sort of doing for animation with mecanim although still proprietary.

<comment><USER4> It's disappointing that Autodesk seems to have eaten everything, but does WebGL necessarily help to standardise any sort of 3D asset format?

The (few, simple) WebGL examples I've looked at seem to use JSON to transport the assets from the server to the browser, but the particular representation used is apparently arbitrary.

I admit I'm thinking by analogy, I don't see OpenGL itself having helped standardise asset formats, so I'm wondering if WebGL is different here.

<comment><USER5> There's a new Khronos project glTF which wants to establish a standardized run-time file format for 3D assets: [http://www.khronos.org/gltf](http://www.khronos.org/gltf), geometry is stored in binary blobs so they can be dumped directly into buffer objects, and the scene description is in JSON for simple (and somewhat fast) parsing. Unlike FBX or COLLADA this is meant as an "engine file format", not as asset exchange format between 3D packages.

<comment><USER6> glTF seems nice. We are currently adding export support for glTF it to our tool - [http://clara.io](http://clara.io). glTF is very similar to the run- time format used by both [http://Verold.com](http://Verold.com) and [http://Sketchfab.com](http://Sketchfab.com) but it is standardized.

glTF is basd on Collada pretty closely I understand.

</comment></comment></comment></comment><comment><USER6> This is nice addition (as in complimentary) to the Alembic format, see here:

[http://en.wikipedia.org/wiki/Alembic_(Computer_Graphics)](http://en.wikipedia.org/wiki/Alembic_\(Computer_Graphics\))

In high end visual effects should should be quite useful. Just to be clear, it isn't intended for games or real-time 3D graphics. It is designed for huge complex scenes where one wants to have delayed loading and renderer integrations.

I have been hearing about this for some time.

It isn't clear how quickly this will be embraced by 3D content creation vendors as it can significantly increase interoperability and reduce lock-in.

Here is the overview of the format and motiviation:

[http://graphics.pixar.com/usd/overview.html](http://graphics.pixar.com/usd/overview.html)

<comment><USER7> I wouldn't call it an "addition" exactly.... It could be used in conjunction with it, as the overview points out, with the Abc files being used as the leaf nodes for the actual geometry representation.

But the SceneGraph representation (USD) will need to be the starting point, as Alembic doesn't (yet) provide a nice way of doing overrides or referencing other external files which is what this spec provides.

<comment><USER6> I meant "addition" in the sense of a complimentary tool set to Alembic. :) But you are right that it can be misinterpreted.

</comment></comment></comment><comment><USER7> It should be noted that this is designed for _huge_ production scenes, with lots of overrides of attributes down the SceneGraph and lots of referencing.

This is not a replacement for FBX or other object interchange formats - it's for entire scenes.

Most big VFX studios will already have their own version of this already in use. What's interesting is it's Pixar pushing this, who don't tend to work with other VFX studios on sharing assets and shots.

</comment><comment><USER8> Is this something that POVray could use? I enjoy playing around with POVray a bit but it would be cool to have a standard language to move between small, consumer oriented tools.

</comment><comment><USER9> For someone not from the world of 3D rendering and animation, can someone please explain in layman's terms exactly what a scene description format does beyond the obvious?

</comment><comment><USER7> USD being used in Katana: [https://vimeo.com/76739820](https://vimeo.com/76739820)

</comment><comment><USER10> The pdf mentions Ogawa as possible replacement for BDB (BerkeleyDB) - <USER2> knows what it is?

<comment><USER6> Ogawa is a new multithreaded binary backend for the Alembic file format. I wrote about Ogawa here:

[http://exocortex.com/blog/alembic_is_about_to_get_really_fas...](http://exocortex.com/blog/alembic_is_about_to_get_really_fast)</comment></comment>


Microsoft vs. Google in the Cloud - <AUTHOR> http://redmondmag.com/articles/2011/02/01/clouds-collide.aspx

<comment><USER2> I just went to Microsoft Azure presentation to technology influencers weeks ago and it was pretty awesome in terms of business value. However I think both of them should stay on each's one side. Google Mail services are way far better than Live and .Net capabilities on Azure are pretty interesting.</comment>


For an Inclusive Culture, Try Working Less - <AUTHOR> https://hackernoon.com/for-inclusive-culture-maybe-less-is-more-87b663662cea <comment><USER2> Yes, yes, yes.

This was brought up in a thread last week about "As a female, how do I identify a good employer?"

The best answers basically said "work somewhere that has as boring a corporate culture as possible". Basically, work for a place where you are rated on your production and nothing else. Work elsewhere and things like "how late did you work?" \-- a metric that is far easier for people without children to meet -- cease to matter.

Working late isn't the only thing (though it is a big one), but it tends to correlate with "immature HR practices" in general. Inclusivity is about recognizing that people have life configurations that differ from your own, and creating the space for those differences to exist.

<comment><USER3> Damn, all this corporate bashing during the last years... It sounded so right. Having worked at several startups in these years, and also co-founded one, I realized the culture is often borderline insane. Working now at a more or less corporate startup, I'm so much happier.

<comment><USER4> It is not insane... if you are 24 with no family. Everyone thinks that startups are populated by young, single 20-somethings because those are the people who take risks and disrupt the status quo, when actually, it is because they are the only people who can put up with that lifestyle.

<comment><USER5> Even if you're 24 with no family... there are better things to be doing with your life than working 10-14 hour days. Some unsolicited advice: don't wait until your 30's to figure that out.

<comment><USER6> my background was working fast food, being a day labourer and long periods of unemployment. I knew this from day 1 going into tech. I find people who come from wealthier backgrounds than me tend to over work.

</comment></comment></comment></comment></comment><comment><USER7> For all the noise tech startups make about meritocracy, they sure do a poor job of separating the work from personal issues which spells doom for minorities in a lot of instances.

I lost count of how many times, something innocent like not going to lunch with the team regularly (I'm a picky eater), or participating in whatever game the team was nuts about (foosball, or various exotic board games) turned into personnel issues where all of a sudden I was "unavailable to the team", or "distant and aloof" etc, even though my professional contributions were just fine or even stellar.

You can imagine how stressful it is to show up to work everyday wondering what bullshit non-work related nonsense is going to come up that day and require another stupid chat with your manager. And in the midst of that you're expected to keep up a cheerful demeanor and work well with the same assholes that keep bringing up this irrelevant crap because the fault in these interactions couldn't possibly be with them.

The day it becomes about the work, and not personal discomfort with new and differing points of view about communication and interaction, diversity at tech companies will become an after thought ... in a good way.

<comment><USER8> Ps... did you do anything to become less unavailable to the team? Like standup meetings or scrum. Or any other interesting strategy.

<comment><USER7> I was never unavailable in the first place, thats kinda the point of the story.

</comment></comment></comment><comment><USER9> > That's because the culture was mostly about the business of software, how > you build it, how you sell it, how you support it. If you were excited about > that, you automatically belonged. You didn't need to stay late, or drink > alcohol, or play Rock Band, or play board games, or not have kids to pick > up, or go to church, or not go to church, or do anything except show up > 9-to-5 and care a lot about good software.

Yes! Yes! Yes!

I don't drink, and its kind of sad that I get to miss out sometimes because I don't go to the bar. Because I like to bike instead, why can't I not feel pressure to go to the bar and do my own thing after work?

Handling work stuff at Work I feel is the way to go.

<comment><USER10> > I don't drink, and its kind of sad that I get to miss out sometimes because > I don't go to the bar. Because I like to bike instead, why can't I not feel > pressure to go to the bar and do my own thing after work?

Because having a liminal zone where people feel allowed to step outside the hierarchy and say things that might otherwise be unacceptable (e.g. "this framework we're using is totally fucked") is really important and valuable? It's not about the alcohol per se, but alcohol is a particularly effective way of creating that atmosphere.

<comment><USER11> If your organization can't encourage frank discussion about workplace issues without a venue for employees to drug themselves, you probably have more important problems to dive into.

More importantly, if you lean on off-site drinking as your method to get real feedback and communication, you probably have less incentive to fix your workplace culture in the first place.

<comment><USER12> Congratulations on missing OPs point. Completely.

A bar is a pretty standard watering hole where you go to complain about things you'd like to complain about off the record. Maybe the problem is annoying and not fixable, e.g. "this framework sucks", or the problem is with with the industry, e.g. "diversity shouldn't be priority over merit".

Both of these problems don't really belong in a "realtime feedback and communication" system because they can't be fixed through the proper channels. The second one especially, where voicing that opinion in SV will get you hung on a cross outside Google HQ.

The bar provides a cathartic release so you don't explode at work on problems you can't fix. Why do you think people stop at the bar before going home? Most of them aren't alcoholics, they just don't want to bring unfixable problems home, and face it, complaining _feels_ good.

<comment><USER11> If you're in danger of 'exploding at work' or have problems that can't be fixed through the proper channels, maybe you should focus on dealing with those issues and opening lines of communication instead of getting people to meet up at the bar after work to instill a sense of team that excludes pregnant women, older individuals, people with kids, people who don't drink, etc. I don't have drinks with my work buddies so that I don't explode. I have drinks with my work buddies because I like catching up with them and sometimes we're too busy at work to shoot the shit.

I don't think anyone has an issue with a few co-workers occasionally grabbing a brew after work. The problem is when people feel pressured to do so because the post-work ritual is replacing actual candid work discussion. Why? Well, its pretty simple. Not everyone drinks. Not everyone has the time to grab a drink after work. Not everyone feels comfortable in a bar around intoxicated co-workers.

There's a marked difference between a few co-workers grabbing a beer occasionally and friday night pints being the only place you can discuss problems you're facing at work.

<comment><USER12> > Implying you have to drink at a bar

> If you're in danger of 'exploding at work' or have problems that can't be > fixed through the proper channels, maybe you should focus on dealing with > those issues and opening lines of communication instead of getting people to > meet up at the bar after work to instill a sense of team that excludes > pregnant women, older individuals, people with kids, people who don't drink, > etc. I don't have drinks with my work buddies so that I don't explode

Second to the above - thanks for getting semantic with me. I don't see how a bar excludes any of these people. Maybe where you live they check green cards and do ultrasounds at the door, but where I live anyone can walk into a bar and not feel compelled to drink. You seem to be really up on the inclusion game though. Why shouldn't people be excluded from certain conversations? Should I invite everyone to my complain fest about a framework they love because I hate it? I can't just leave my job, so I go to a "place" (since you seem to have this internal fixation with bars and alcohol) with "receptive people" (since you seem to think exclusion implies leaving out minorities) that can assure me I'm not alone in this world. Additionally I drink at that bar because an ice cold pint at the end of the day is great and it's a thing we all have a common. I don't drink so I don't "explode". I'm really regretting using that word because people like you fixate on minutiae so you don't have to argue an actual point.

I don't think you're nearly as level-headed as you think are you are. Everyone "winds down" some way. I prefer the bar, some people prefer a picnic at the park. There's a bar down the street from work where I can complain with people friendly to my cause about things that bother us. I don't see why this is such a problem. It's almost like you're discouraging human interaction in the name of this ambiguous spectre that haunts SV - "inclusion at all costs".

<comment><USER11> Oddly personal response. "Thanks for getting semantic with me", "People like you", "You seem to have this internal fixation with bars and alcohol", "I don't think you're nearly as level-headed as you think you are"

Again, I don't care if people grab a brew after work. I care if an organization's culture excludes those who don't.

Since the topic seems a bit close to home, imagine this: you work at a start- up and the founder only seeks frank input about how things are going during weekend sailing regattas. The two teams that are led by sailors keep having their roadblocks removed, while the rest aren't. Comparisons between the sailor led teams and the others are driving negative performance reviews for the teams you're a part of. Do you think this is healthy for the company?

<comment><USER13> It is objectively healthier for the company to have two teams with roadblocks removed rather than no teams having their roadblocks removed.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> This is all fine, but there are side-effects.

If you only work a minimum number of hours within your field, you are unlikely to emerge as one of the peak achievers or thought leaders in your field. That's just because you learn more from experience, and working more hours gives you more experience.

You can extrapolate from there what this means for companies and individuals.

I am not at all saying that companies should ask people to work long hours. (I run a software company, and we are super-lax about hours, people showing up at the office, etc). But I am saying that if an individual wants to be an expert in a particular field, that person should probably work a lot (and probably wants to work a lot anyway, due to interest in the subject). This doesn't necessarily have to be at the company; it could be at home, on personal projects, whatever. But the deeper and more challenging the project is, the better you learn, and it's easier to have one project that is deep and challenging than somehow to have two in parallel. And if only one is deep and challenging, then you are sort of idling with half your time. So there are basically two paths to this kind of deep work: work for a company, make sure you get a project that's really good, and then work hard on it; or go do your own thing, make sure you have enough money somehow, and work hard on what interests you.

This also means that "work-life balance" is not a thing for experts the way it is for normal people. But that's fine, because for these kinds of experts their work is a serious part of their life and the two things are inseparable.

Of course if you don't feel this way about what you're working on, that it is a serious part of your life, then this strategy doesn't make sense; and I would not encourage people who don't feel this way (who are the majority of the population) to work that hard. I am just pointing out that there are some of us for whom a different life strategy is best.

<comment><USER15> "This also means that "work-life balance" is not a thing for experts the way it is for normal people. "

I have seen quite a few experts in their field and they didn't work long hours but everything they did counted. The problem is that most of us are being overloaded with repetitive, trivial stuff and never get the opportunity do deep thinking and solving difficult challenges. This can't be solved by working more.

You pretty much wrote this but I just want to emphasize that long working hours won't get you ahead but challenging work.

<comment><USER16> I have observed that most of the people I know who fit your description: experts who work fewer hours but everything they do counts, almost always went through a period of ridiculous and obsessive long hours early in their career.

Once you've built that skill set, it makes sense to dial things back because you now know how to be effective and you also probably do tons of mental work semi consciously away from your "desk."

But it drives me crazy how people seem to think they can start out that way. In my experience that is a sure path to modest abilities, which is fine, but that's the trade off.

<comment><USER15> "almost always went through a period of ridiculous and obsessive long hours early in their career."

Maybe. But for sure they worked on something challenging and not on checking off endless lists of JIRA tickets. It's not long hours but quality of work that makes you grow. Both together is probably the winner.

</comment></comment></comment></comment><comment><USER17> I think he's taking the surface level and assuming if we copy the surface level, we are going to get the rest.

No.

The reason Fog Creek works well, is because it's very smart people, who care about what they're doing. They care because it's a product company - they get to make decisions that impact the product. They feel a sense of ownership.

Contrast that with a sweat, uh sorry, I mean dev shop. Contrast that with doing contract work for big companies where you come in, leave 6 months later. Contrast that with start-ups that only exist because someone got free money.

Contrast that with shit maintenance work at big corps.

Does that about cover 95%, if not more, software jobs out there?

There is no fixing shit workplaces because the foundation is rotten. When you have no say, when you don't care about the product, when you move around every few years - yeah, it's shit culture.

There is no fixing that - most people long for a stable group of people they can make something happen with.

Most people are confused about how much work and dedication it takes to make something great. Most people's actions create what most people complain about and they don't even know it. There is no fixing it, there is only becoming good enough to either start your own Fog Creek, or be good enough to join one.

</comment><comment><USER18> >Yesterday, I had a wide-ranging Slack conversation with some very nice people who patiently allowed this privileged white male to repeatedly touch the third rail of diversity and inclusion.

Read this three times and I can't understand what it means. Can anyone "translate?"

On the overall topic, it seems really obvious in retrospect that removing formalities in the workplace turns the office into a social club and those who don't want to socialize are excluded. Its certainly an unintended consequence though.

I can certainly see the benefits of formality in the office now that I'm older.

<comment><USER19> Current social norms require a degree of self-abasement before it's socially acceptable for certain types of people to offer an opinion on certain cultural topics. This is a ritualized phrase designed to fulfill this norm. It's not intended to convey any information.

<comment><USER20> I wish to subscribe to a newsletter in which you annotate, line by line, speeches by politicians and other popular figures.

</comment></comment></comment><comment><USER21> I am going to wrap this article around a bigger more general concept. I might be going off topic but bear with me.

The difference between a startup culture and a corporate culture is the difference between a creative company and a disciplined company. "Discipline" is like a swiss knife, something that can work anywhere and everywhere. Creativity only works in some places, in places that are desperate, in places that are still making basic decisions, in places where the problems are high and the solutions are few.

A disciplined company has no problem being acquired by a creative company. But a creative company has many problems when they start masquerading in a disciplined company. (Read: Microsoft acquires Company X and writes it off 5 years later.)

Working in a disciplined company is easy for most people. No manual required. Working in a creative company is difficult for most people but easy for creative people. Most foreigners or people with diverse minority backgrounds have a difficult time adapting to very social environments. They would rather stay strictly professional and confined to their work.

But here is the problem: what is the point of having diversity if social interaction is nil? How messed up is your social world if it does not include unsocial minorities?

There is a balance that is needed. Google started as creative and became more corporate and also became more "boring". (Sergey Brin's word)

<comment><USER22> "Most foreigners or people with diverse minority backgrounds have a difficult time adapting to very social environments. They would rather stay strictly professional and confined to their work."

Maybe rephrase this sentence, this reads like anyone not like you cannot do creative work. It sounds extremely racist and other 'ists.

<comment><USER21> I guess I stepped on a racism mine, even if I happen to be of a minority myself.

</comment></comment></comment><comment> temp-dude-87844 This approach finds its parallels in other collaborative spaces where meritocracy is valued; open source software development comes to mind. In that arena, this approach was widely deployed, but is at odds with the more recent trend of explicitly stating to promote inclusion and diversity.

Staunchly meritocratic online interaction and collaboration, from software development to messageboards, allows people to cultivate identities largely defined by their contributions, which is often distinct, or even at odds, from the identity they wish to demonstrate in their real life. In online spaces where individual contributors aren't restricted from speaking out against the leadership, this disconnect will manifest instead of being suppressed.

While I don't disagree with the author's recommendations and rationale, it's unfortunate that the OP's argument essentially reduces down to the fact that the less casual interaction between people, the more inclusivity will result. It's also re-framing the implied problem: the equality vs. equity debate. In the OP's view, the solution is to cultivate a minimalist, work-focused culture that solves the inclusivity question by avoiding it entirely. This is very much at odds with the approach that receives a lot more press these days, which seeks to prescriptively address inclusivity within its own problem- space.

<comment><USER23> How are you defining "meritocratic online interaction"?

<comment> temp-dude-87844 A contribution defined by its payload's self-contained substance and value-add to a core mission of the effort, e.g. a block of code for a requested feature, documentation to accompany a feature, an insightful on-topic post, or a stimulating exchange.

It's an artifact whose value is derived from its content, and not from its provenance.

<comment><USER23> OK, I'll bite.

In principle, this makes sense, but I think if we poke at it a little you may agree that there are some holes.

>A contribution defined by its payload's self-contained substance and value- add to a core mission

Let's discuss the core mission. How is this mission decided? Is there a process that includes multiple stakeholders? Who picks these stakeholders? I would presume that most open source projects are started by 1 person, or a few people who work together, but recognize that other arrangements exist. At some point either they must set these goals or expand the core group that makes such decisions. So to start with, the first person(s) setting the mission are as arbitrary as having been there when it started. Are they the best at setting goals once a project is in full swing? Perhaps, perhaps not. But, I think you can agree that at the outset, merit is defined by those who start a project or are arbitrarily close to it's start.

> It's an artifact whose value is derived from its content, and not from its > provenance.

How does a project determine the "value" of a piece of content. What is the process for derivation? Is it simply the fulfillment of a feature request with accompanying tests and docs? I would suggest that for any non-trivial code, it will be difficult to determine if a pull request will do exactly what it is purported to do with no negative externalities.

What is you have competing contributions for the same feature request? How do you determine which one to choose? Let's say for example that concurrently an issue is addressed by a core contributor and a first time contributor and both arrive at equivalently good solutions. Which implementation should you choose to maintain "meritocracy"? How do you justify that decision?

You may be interested to look to the origin of the word meritocracy[1]. It was intended as satire.

[1]The Rise of the Meritocracy [https://books.google.com/books?id=QelNAQAAQBAJ](https://books.google.com/books?id=QelNAQAAQBAJ)

<comment><USER24> I think you're talking a bit past temp-dude-87844's point.

Yes, a system based entirely on the contents of the contributions will end up modeled by the biases of those who take the decisions. But aren't those the same forces that would apply to a "work-focused" company environment like the article proposes?

</comment></comment></comment></comment></comment><comment><USER10> > It's so comfortable and nice to lead an integrated life where your > colleagues are your friends and vice versa, where your conversations over > beers solve problems encountered over keyboards.

> But maybe that comes at a cost. If we set aside that desire and focus on > what we're really trying to do here — make good software — then maybe we'll > open up some different possibilities. By constraining the number of things > we have to agree on, and the number of hours we have to spend agreeing on > them, we naturally open ourselves to a diverse world of talented people.

Much as we might wish otherwise, I think this article is right that informality and diversity are in tension (though I think it's massively wrong to conflate informality with long hours; it's very much possible to have a culture where you drink alcohol, play Rock Band, play board games, but still go home after your 35 hours/week). But having to give up informality would be a very heavy price. For me a comfortable life is the end and making good software is the means. But even if your goal is good software, looking at the past couple of decades of big professional companies being displaced by scrappy startups, _informal organizations seem a lot better at producing good software_.

<comment><USER25> > For me a comfortable life is the end and making good software is the means.

I have a comfortable life. It involves being on a kayak with my wife and kid, not hanging out with coworkers.

> But even if your goal is good software, looking at the past couple of > decades of big professional companies being displaced by scrappy startups, > informal organizations seem a lot better at producing good software.

Are startups "better at producing good software?" They may be better at entering novel markets, software that's novel isn't the same thing as software that's good. _E.g._ Facebook's iOS app used to be a buggy piece of crap. It's gotten much better as Facebook as gotten more "corporate." Some of the best software I've used in the last decade was made by Apple, which hit a billion dollars of revenue the year I was born.

<comment><USER10> > I have a comfortable life. It involves being on a kayak with my wife and > kid, not hanging out with coworkers.

Having friends in work is no barrier to spending time with other friends or family outside of work - it's not zero-sum. Even 35 hours/week (and if you've got a better deal than that then I envy you) is a lot of time to be spending with a bunch of people none of whom are your friends.

> Are startups "better at producing good software?" They may be better at > entering novel markets, software that's novel isn't the same thing as > software that's good. E.g. Facebook's iOS app used to be a buggy piece of > crap. It's gotten much better as Facebook as gotten more "corporate."

Users vote with their feet for featureful-but-buggy over well-engineered-with- less-cool-functions, and I don't think it's because users are stupid. I think a willingness to "move fast and break things" translates into genuinely more life-enhancing software on the whole.

</comment></comment></comment><comment><USER26> It is also known that casual dress is somehow connected to less social mobility.

> But above all I didn't have the cultural and social capital to know how to > dress casual in the right way. My casual dressing was made of nerdy, > unfashionable and cheap clothes: you could immediately say that I haven't > accomplished anything. And I didn't even know that there was a "rich" way to > dress casual.

[http://marginalrevolution.com/marginalrevolution/2017/05/inf...](http://marginalrevolution.com/marginalrevolution/2017/05/informal- dress-social-mobility-sicilian-perspective.html)

there's more art to looking sharp in casual attire than in a suit and tie!

> Tyler Cowen: Well, being a casual person myself, I'm very glad being casual > is in vogue, and probably will stay in vogue. But what I find striking is > societies with a lot of upward mobility often tend to have strict dress > codes. So you see this today with Mormons, at Mormon businesses. You see it > in Japan in its heyday years--you know, the businessman or journeyman suit, > they more or less all looked the same. There's something about upward > mobility where actually clothing is not that casual and one is being more > formal in trying to impress; and that is a [?]. But the thing about being > casual is it actually makes it harder for people to prove themselves. So, > Bill Gates goes to a meeting and he may show up dressed very casually; but > he's still Bill Gates--either everyone knows or if you really needed to, you > could Google him. So there's a code of casual that's actually very difficult > for, say, people from other cultures in America to master or demonstrate > that's actually made signaling harder. Just that right way of looking casual > is in a funny way more conformist than like the blue suit and tie, which you > could do and then innovate around and try to climb to the top. So I find > this disturbing, the more I think about it.

[http://www.econtalk.org/archives/2017/05/tyler_cowen_on_1.ht...](http://www.econtalk.org/archives/2017/05/tyler_cowen_on_1.html)

<comment><USER27> I listened to that podcast, and I think the money quote is this one:

> Russ Roberts: […] I do think it's--instead of getting a very highly tailored > and expensive suit, now you have to know exactly how to match your tee-shirt > with your running shoes in a way that doesn't make you look the wrong kind > of geek or whatever it is.

> Tyler Cowen: Yes, so say you are an immigrant to this country and you show > up at a workplace and they tell you, 'Look, put on a blue suit jacket and a > tie, and burgundy shoes.' I mean, don't you feel immense relief at that, > actually?

<comment><USER26> right, though i thought the guests other points were overall garbage

</comment></comment></comment><comment><USER28> I wish I could up-vote this more.

It is a problem that corporate America tries to optimize function by getting everyone closer and closer together with team building exercises and alignment of values.

Values are deeply personal and we should recognize that people are going to differ. Freedom of conscience is as basic as freedom of religion and important for the same reason.

If we keep work a professional space we maximize diversity of thought and life experience, which are ostensibly what the large push toward ethnic and gender diversity are a proxy for.

</comment><comment><USER29> The takeaway for me is less about minimum hours and more about minimum culture. Or put another way, "keep your identity small". [http://www.paulgraham.com/identity.html](http://www.paulgraham.com/identity.html)

</comment><comment><USER30> Maybe this is more about drinking than dress code. Companies of Japanese salarymen have the same problem - too much group drinking, and a very uniform culture.

</comment><comment><USER31> Sometimes, to solve really difficult problems, you have to make big personal sacrifices.

Sometimes, to evolve, adapt and gain the edge, you have to be loose and unprofessional.

Sometimes, to survive a famine or a drought, you have to ruthlessly cut what isn't absolutely necessary.

These are the other phases of the business cycle that the author neglects. Professionalism, openness, and work life balance belong to a certain phase of the cycle. That phase does not come from nothing and it does not last forever.

</comment><comment><USER32> Why does racial and gender diversity matter in tech? I have worked in teams of all white guys and teams of mixed race and gender and I have seen no difference in productivity. The only thing that ever mattered was the skill level of the people. I see nobody complaining that most successful basketball players are tall black people.

I don't see a problem with having companies with corporate culture and companies with startup culture side by side, just because I dislike the suite and tie culture doesn't mean I want it gone, however from reading the article I get the impression that the author wants the more liberal companies gone just because he doesn't like them.

</comment><comment><USER33> The assumption seems to be that companies culture is driving women away. Is that even true, as in, are there really hundreds of thousands of female software developers in waiting who would jump at a job at a company with the appropriate culture? It seems very unlikely to me - more likely, the pipeline dries out long before the hiring stage.

That some companies with great effort manage to compete over the few female developers on the market doesn't prove every company could hire lots of female developers if only they changed their culture.

To be honest, personally, even if there were those hundreds of thousands of female developers supposedly driven away by bro culture, I would still maintain that people should have a right to create companies they enjoy working in. If some people want to work in T-Shirts and get drunk every night, it is their right to do so (if they can earn the money to sustain it).

Luckily not all companies are the same, so that people can apply to companies that suit their tastes.

If it weren't so, there wouldn't even be a need for hiring or job seeking to begin with. People could just apply to the next best company and be hired, likewise, companies could hire the next best applicant - because there would be no such issues as cultural fit or whatever. Not very realistic (source: I am not friends with everybody and not everybody is friends with me).

</comment><comment><USER34> Overall good post, but:

 _Yesterday, I had a wide-ranging Slack conversation with some very nice people who patiently allowed this privileged white male to repeatedly touch the third rail of diversity and inclusion. That conversation led me to the realizations in this post. I'll thank them by not naming them, and by promising never to bring this up in their Slack channel again._

In other words, people openly hated on him for wanting to discuss something with them and get informed -- a white male in a position of power that few women or poc occupy. And all they can do is make him scared to bring it up again and act like the abuse they heaped upon him is some sort of privilege he didn't deserve or something.

Wow.

I am so sick of women and people of color being openly hateful to people who were born the "wrong" gender and color to be part of the unfortunate many. Hello? Whining about how "it isn't my job to explain this stuff to you!" instead of being all "OMG! An opportunity to have a useful conversation with a white male who is actually curious about how the so-called other half live!" is part of the problem, not part of the solution.

(Before you auto-downvote this on the assumption that I am some overprivileged asshole man, please note I am a woman.)

<comment><USER35> "I am so sick of women and people of color being openly hateful to people who were born the "wrong" gender and color to be part of the unfortunate many."

Really? So now being born white and male is the "wrong" color and gender? Those are identities that are near the apex of privilege in our society. As a white man, being afraid to ask questions for fear of being unintentionally racist or sexist is nowhere near comparable to the actual experience of racism and sexism. God forbid we hurt a white man's feelings while discussing social justice. That would be a true injustice.

<comment><USER36> This is an infuriatingly unhelpful attitude.

Presumably the goal is to encourage people who lack awareness about issues surrounding racism and sexism to both become aware and to actually care about these problems. And to change their behavior, to the extent that it should change.

Unnecessarily attacking, humiliating, or embarrassing a person who is willfully admitting their own ignorance and seeking a better understanding of the situation is so obviously counterproductive that I can't believe I'm having to write this comment. This is not the way to win people to your side — in fact, it's completely the opposite. Doing so only causes both sides to become more firmly entrenched in their beliefs and less likely to try and discuss the issue further. By giving them a positive experience, you not only increase the likelihood of them seriously considering your arguments, but you also open the door for them to come back to the table for discussion again, even if you didn't win them over the first time around.

<comment><USER37> Right - clearly it is the job of women and PoC to give positive experiences to white men otherwise they cannot expect to be treated well.

It is also clearly not the responsibility of white men to give positive experiences to PoC and women, because they can't be expected to understand how if they aren't first given positive experiences by PoC and women.

<comment><USER36> It's not a duty or responsibility. And it's not _un_ productive as a sibling commenter suggests. It's straight up _counterproductive_ and a form of self- sabotage.

If your goal is to feel self-righteous and superior, by all means attack those who are showing genuine interest in coming over to your side. If your goal is to actually bring about a positive change in society, perhaps it's worthwhile to consider a different approach.

<comment><USER37> This is based on an almost ludicrously simplistic straw man: you conjure up the idea of someone who is "showing genuine interest in coming over you your side"

How are they 'showing' this exactly? What makes it 'genuine' that they want to come over to another side? Why are they on a 'side' in the first place, and what makes you think that the goal is to have them change 'sides'? Are you saying they are not already on 'our side'? What does that imply? How can you distinguish their arguments from those of people who simply want to argue their position and remain ignorant?

</comment></comment></comment></comment></comment></comment><comment><USER38> Remote work is even more inclusive.

<comment><USER39> Remote work, in my experience, also tends to be managed/ rewarded largely on the basis of productivity.

</comment></comment><comment><USER40> The whole article is brilliant. I'd argue one great way to make this happen is remote work. Agree on some basic tools for text and voice chat and you're good to go. No stupid bro culture. No having to be seen working late. No dress codes. No bullshit. Either you create the product or you don't and get fired. Been working for years for my company and many others.

</comment><comment><USER41> There's no shortage of corporate environments to work in for those who want it.

</comment><comment><USER42> Am I the only one who gets the niggling feeling that anyone who uses the words "males" and "females" in their public dissertations like it's normal to refer to people the same way one does cable connectors must have a tenuous and possibly weakening grip on the real world?

<comment><USER43> _> Am I the only one who gets the niggling feeling that anyone who uses the words "males" and "females" in their public dissertations like it's normal to refer to people the same way one does cable connectors must have a tenuous and possibly weakening grip on the real world?_

I hope you are, because I don't think your "niggling feeling" has any rational basis. If you want to indicate the gender of a person, there is absolutely nothing wrong with using the terms "male" or "female".

I guess I need to clarify that I'm using the term "gender" in the traditional, biological sense of the word, rather than the current fashionable sense that vicious scolds and busybodies insist that everyone must use.

<comment><USER25> > If you want to indicate the gender of a person, there is absolutely nothing > wrong with using the terms "male" or "female".

In English, "man" and "woman" are the preferred terms for male and female humans, respectively. "Male" and "female" are clinical and dehumanizing. It's like saying "Laura is gestating an embryo" instead of saying "Laura is going to have a baby." They're also just grammatically weird, because they're adjectives that have been turned into nouns. It's like saying "Ben is a Hispanic" instead of "Ben is a Hispanic person." Finally, they're one letter longer for no benefit.

Neither of the reasons people use "male" and "female" instead of "man" and "woman" are any good. The first is attempting to sound educated by using French-derived words like male and female in preference to German-derived words like man and woman. The second is that "male" and "female" punt on having to refer to the person's age, and in our era of perpetual adolescence people are terrified of being considered a "man" or a "woman."

<comment><USER43> _> In English, "man" and "woman" are the preferred terms for male and female humans, respectively. "Male" and "female" are clinical and dehumanizing. It's like saying "Laura is gestating an embryo" instead of saying "Laura is going to have a baby." They're also just grammatically weird, because they're adjectives that have been turned into nouns. It's like saying "Ben is a Hispanic" instead of "Ben is a Hispanic person." Finally, they're one letter longer for no benefit.

Neither of the reasons people use "male" and "female" instead of "man" and "woman" are any good. The first is attempting to sound educated by using French-derived words like male and female in preference to German-derived words like man and woman. The second is that "male" and "female" punt on having to refer to the person's age, and in our era of perpetual adolescence people are terrified of being considered a "man" or a "woman."_

No offense, rayiner, but I think everything you wrote is simply ridiculous on its face. Saying they're "clinical and dehumanizing" or "grammatically weird" are simply your opinion, which I do not share. And saying that "they're one letter longer for no benefit" just smacks of desperation.

If you want to indicate the gender of a person, there is absolutely nothing wrong with using the terms "male" or "female".

But, as evidenced by this thread, there are people who want to make that usage taboo.

<comment><USER44> There is a reason that the Ferengi on Star Trek referred to women as females. It sounds weird and dehumanizing. This isn't a new thing either. The first Ferengi episode aired in 1987.

You can obviously believe what you want but know that people will judge you in a negative light if you talk like that.

<comment><USER45> To me these terms simply sound like how a biologist would talk about animals. But it seems they are indeed gaining traction among feminists for reasons I haven't cracked yet.

<comment><USER25> Relevant: [https://www.youtube.com/watch?v=gYRTmvhOOVU#t=30s](https://www.youtube.com/watch?v=gYRTmvhOOVU#t=30s).

</comment></comment></comment></comment></comment></comment></comment><comment><USER46> So by forcing everyone to work strict 9-5 schedules you can create diversity. Ok.

Hmmmm... I agree at least in principle that one shouldn't be required to always hangout late nights after work. However, admittedly occasionally I think it's useful and it's helpful to understand your co-worker's motivations and spending a bit more time with co-workers sometimes is certainly reasonable and helps to build trust and respect amongst other co-workers.

Maybe people should be working only 30 hours a week and spending the other 10 hours just on team building.

I also think its useful to understand the social aspect of things because understanding motivations can help the team solve problems in a way that everyone will agree to.

<comment><USER18> 10 hours a week on teambuilding seems extremely excessive.

The thing is, many people don't want personal relationships with their co- workers, they want business relationships with their co-workers. Forcing employees to socialize with each other means you are excluding those people who don't want to socialize with their co-workers and those who don't have much in common with their co-workers, or even those who don't like their co- workers on a personal level. This seems pretty obvious, but only in retrospect.

I also don't understand what "understanding motivations" means.

<comment><USER46> I would love to be in agreement with you but my experience has taught me differently. Social relationships are business relationships. There isn't a way to separate the two. If you don't like someone you work with directly eventually one of you will leave if you both are working two closely together. The tension could also cause other business problems in some form or another over time. 9 to 5 doesn't work for everyone.

For some people working different schedules is what works for them. What about that type of inclusion? Inclusion of those who don't want to do the standard 9 to 5 and those who do want to socialize with each other.

I think there is a tendency for individuals to do 180 on business-related processes every time a new article comes out about some business is doing X and it appears to be successful for now.

When times are rough having a social relationship will help keep the business part of the relationship in tact. Things will not always be easy and there will be rough patches and stressful situations. It's also helpful to meet and get to know people in other departments before you need them for something.

If you work in any kind of large organization with lots of departments and moving parts you will need to know now to navigate the organization. Social situations allow you a chance to build relationships with people working on other parts of the business that you may or may not need help with later on down the line. People have to socialize with each other to get work done. It's not an option to not have at least a somewhat social relationship with someone you work with closely. It's not realistic.

Yes, I think it's helpful to understand someone else's point of view(and/or motivations) and where it comes from. Knowing these things can stop you from being offended by something that may be said or done that wouldn't otherwise be considered offensive. Many times you will already know how someone will react to certain situations and decisions as well as figure out ways to effectively navigate that.

Its easier to get a co-worker to care about and help you with your problem if you have some common ground with a co-worker or some social capital. A "business only non-social" environment means you have a whole bunch of people working who ultimately undermine each other.

You wind up with duplication of effort etc... I've had people tell me flat out tell me they don't want me to tell them the solution to the problem they were having that was already solved because they wanted to figure it out by themselves. This type of "business-only" competitive attitude is wasteful of the businesses time and money. This happened at one company I worked at who was steadily laying folks off while this sort of wasteful behavior was happening.

All in all trying to take the people out of the people in my almost 10 years of experience doesn't actually work out well and can actually be wasteful and hurt the business.

<comment><USER18> Complete and utter nonsense.

Business and personal relationships can most certainly be separated, it just takes the right mindset and the willingness to set personal boundaries. However, if you are telling your employees "come in in shorts, drink beer, don't leave the office, we are all just friends here" you're intentionally putting up barriers to forming that mindset.... You don't have the same sort of relationship with your dad as you so with your spouse as you do with your best friend as you do with your good friends as you do with an acquaintance as you do with a stranger. This is normal.

Learning to work well with people who you don't particularly like is a skill. One that is learnable. Children have problems with it but adults should know better and if they don't know better they should be fired and replaced with people who can act like adults. "Working well with others" is something one is taught in kindergarten, it is mandatory for the workplace.

There's plenty of people I don't particularly like that I work with, that I know I wouldn't get along with on a personal level but I don't have issues working with them. People who I hold very, very different core values from me and people who have fringe political beliefs. But I don't have issues with them at work. I wouldn't want to socialize with them though.

Avoiding offending someone is easy, it's called avoiding saying offensive things or things "considered offensive," otherwise known as "being nice to others." Once again, we learned this in kindergarten.

If nobody is helping you with business problems unless you are friends or have "common ground" you have a very, very dysfunctional organization and it needs serious help. Even worse if everyone underminds each other. Not being friends with a coworker is not an excuseable reason for undermining them and at that point you are dealing with an office full of psychopaths and children. Forcing them to socialize with each other isn't going to fix the larger core issue.

What about customers? Do you need to 'get to know' your customers personally before you can work with them too? I'd imagine that would be a huge barrier to new customer acquisition. "Sorry, we can't give you a quote until we 'know your motivations(?)' and get to know your pets names. Meet at the pub at 5?"

The toxic workplaces you have described have nothing to do with a lack of coworker socialization.

</comment></comment></comment></comment><comment><USER47> I'm looking for an alternative framework to work-life balance: [https://news.ycombinator.com/item?id=14538411](https://news.ycombinator.com/item?id=14538411)

I bet there's more than one out there.

Work/life balance doesn't "work" for a lot of people, a lot of types of work and a lot of lives. Astronauts, Presidents, Prophets . . . startup ceo's . . .

<comment><USER2> Work/life balance is often a cyclical thing: during certain periods in your life, you will have more time available and desire to work than others. I don't think there's a one-size-fits-all solution, which is why giving employees the flexibility to figure out what it means for their life is the right approach.

As an employer, you're going to find that giving people the flexibility to manage this for themselves is ideal. The alternative is you get to manage high turnover, which is exactly what happens when companies demand "only the top engineers" and then work them to death with 6 months of unnecessary 100-hour weeks.</comment></comment>


Quality, a user problem - <AUTHOR> http://blog.arc90.com/2010/02/08/quality-a-user-problem/

<comment><USER2> If important updates are lost in the noise, perhaps Facebook is not the place to announce them.

<comment><USER3> That's a solution, but I'd think Facebook would want to avoid their users coming to that conclusion.

</comment></comment><comment><USER4> Poor old Arc90 needs to get some better hosting. Their server always seems to be coughing up blood. And Google doesn't have this one cached yet :(

<comment><AUTHOR> It's Slicehost (Rackspace), go figure :) <http://twitter.com/arc90/status/8828385989>

</comment></comment><comment><USER3> I see two problems with his "volume" solution. The examples given show a fundamental divide: there's the song you've spent years working on, and then there's some random comment someone felt the need to get off their chest. There's one problem with the volume metaphor. How often would people change the volume? What's a mid-volume update, or an update with the volume set to 75%? The second, much bigger problem, is that using "volume" is a confusing interaction; people are already used to using those volume slider controls on websites to control the volume of sounds. The UI is telling them one thing, but the functionality isn't consistent with the typical website experience.

Offhand, I'd say maybe create a separate category called "Announcements" to take advantage of existing psychology and etiquette. Who would "announce" something like "mmmm... Cheetos." or "gonna get my drink on 2 nite!"? Maybe they'd get called "announcement whores".</comment>


A Shipwreck, 500 Years Old, Appears on the Baltic Seabed - <AUTHOR> https://www.nytimes.com/2019/07/22/science/shipwreck-archeology-shipwreck.html <comment><USER2> Off-topic: Are there similar findings not in the sea, but inside the caves? I know that the sea is vast and has been navigated for thousands of years, and that it is even easier to search and find something in its depths. But what about the great caves? Will there be something to find inside them?

<comment><USER3> Similar how? We've made many important finds of homids in caves, but it seems very unlikely we'll ever find some technological artifact comparable to a boat in a cave.

</comment></comment><comment><USER4> [http://archive.is/E9ToP](http://archive.is/E9ToP)

<comment><USER5> This link is also good and ad free

[https://www.southampton.ac.uk/news/2019/07/unknown- ship.page](https://www.southampton.ac.uk/news/2019/07/unknown-ship.page)

</comment></comment><comment><USER6> > _The name and origin of the lost Baltic ship have not yet been identified._ > [...] _Dr. Pacheco-Ruiz and his team are deliberately keeping its exact > location secret, to deter scavengers and treasure hunters._

Is that really possible in this day and age? I feel like there has to be some corner of the internet where some internet sleuths have figured it out.

EDIT: Skimming various Swedish articles, which mention "north of Gotland", between Sweden and Estonia, and on international waters, so probably somewhere east of Gotska Sandön.

<comment><USER7> Not that I'll be doing this, but...

The blurred areas on the ROV video ([https://www.youtube.com/watch?v=3p8TH1tDvzk](https://www.youtube.com/watch?v=3p8TH1tDvzk) ) probably contain location data, among other things.

Considering that we have a nice, nearly black background, and access to the font used, it should be a piece of cake to figure out the censored data. Just blur numbers 0-9 and determine which fit best with the video. See e.g. [http://dheera.net/projects/blur](http://dheera.net/projects/blur)

<comment><USER8> Also, if the blur has a known or estimable kernel[0], you can apply deconvolution[1].

[0] [https://en.wikipedia.org/wiki/Kernel_(image_processing)](https://en.wikipedia.org/wiki/Kernel_\(image_processing\))

[1] [https://en.wikipedia.org/wiki/Deconvolution](https://en.wikipedia.org/wiki/Deconvolution)</comment></comment></comment>


Physicists create quantum 'hard drive for light' - <AUTHOR> https://phys.org/news/2018-11-physicists-simpler-than-ever-quantum-hard.html <comment><USER2> Lindsay is a really great physicist. It's been cool to watch what's been coming out of her lab.</comment>


One Architect's Radical Vision to Replace the Open Office - <AUTHOR> https://www.wsj.com/articles/one-architects-radical-vision-to-replace-the-open-office-11578578407 <comment><AUTHOR> tl;dr -

Rethinking how a space is structured could change the ways people do their jobs, Mr. Dewane says. His solution, one beginning to gain traction across the U.S., is a concept he calls a "eudaimonia machine," its name based on the Greek term for human flourishing. In it, workers move through five or six distinct zones during the day. Each space has a purpose, from socializing to research, allowing people to alternate between focused work and chances to recharge. The design culminates in individual "deep-work chambers," intended for focus. …

Rethinking how a space is structured could change the ways people do their jobs, Mr. Dewane says. His solution, one beginning to gain traction across the U.S., is a concept he calls a "eudaimonia machine," its name based on the Greek term for human flourishing. In it, workers move through five or six distinct zones during the day. Each space has a purpose, from socializing to research, allowing people to alternate between focused work and chances to recharge. The design culminates in individual "deep-work chambers," intended for focus.</comment>


How to Refactor Your Finances – An Interview with a Programmer Who Retired at 34 - <AUTHOR> https://triplebyte.com/blog/refactor-your-finances <comment><USER2> I also liked these quotes from the original interview, but didn't include them for the sake of brevity:

 _On favorite languages /frameworks:_ Ruby on Rails, definitely. I just fell in love with it, it was so much easier to get something built that was actually robust and it didn't feel like it was just gonna break, compared to all the .NET stuff I was doing before. It just made me love programming again, and I still use it to this day. I've built all my custom Mad Fientist stuff with Ruby on Rails, and it's just so easy to put something together, deploy it to Heroku, and then you've got something that's usable. That's exactly what I did for the FI Laboratory. I just threw that together and threw it up on Heroku over a couple of weekends. I always expected to make it nicer and better, but I just never touched it and now it's got 60,000 users, and it's just absolutely crazy, and I'm still hardly paying anything: $29 a month I think.

 _On being extreme with finances:_ Personally, I'm pretty extreme. Every time I spend money, it's like the worst case scenario. So much thought process has gone into it beforehand. It's like, "Could I get it used? Could I borrow it? Do I really need it? Do I really want it?" And then, if all those things happen, then it's like, "Okay. I'll buy it." And then, I try to find it for the best price.

 _On the new iPhone:_ You don't need a new iPhone every year because, guess what? That iPhone 9 only made you happy for what, maybe a few weeks? And then, it was just a phone again until the iPhone 10 came along and you were like, "Oh, that's gonna make me happy." What's important is realizing that about yourself and looking at past purchases, thinking, "Oh, I spent a lot of money on that thing. Did it actually make me happy for very long? Could I have gotten it used instead? Did I need it at all?"

<comment><USER3> For the iPhone, if you want the newest, buy it. Enjoy life. Do everything that makes you happy. We are only on this earth for so long. The best way is to buy the newest iPhone and sell it after a year. Pay the extra $100 to upgrade each year, so you have the latest if it makes you happy. The fire movement is cool, but FATFire is better.

</comment></comment><comment><USER4> Being able to have a tight grip on one's budget is important. It helps you secure your future and provide a better tomorrow not just for yourself but your family, as well.

Check out some of these tips on how you can save more and manage your finances:

 _Create a budget plan according to how much you earn. Your budget and spending should be something that is in-line how much money that comes in regularly. A budget helps you live and experience life to the fullest without overspending. Under-budgeting yourself and your family is also no good since that would mean you are actually lowering your standard of living in some aspects.

_ Make sure that you are sticking to your budget plan. As I have said earlier, a budget plan helps you live life to the fullest without breaking your bank account, and in order for this to happen, you have to stick with your budget as much as possible. Keep a close track of your spending and list down every spending you make. Keep a tight leash to that madman inside you that screams buy this and that that actually do not have any important use t you.

 _Make an itinerary of your daily activities the night before. Having a daily to-do list helps curb your spending urges by reminding you that you are in a saving mode. Having a set routine also helps you become more productive because now, you have set tasks to do instead of thinking what other stuff you can buy.

_ Plan and budget your meal plans. I am one of those people who spends too much money on food. Having a set budget helps you limit your food choices. I live in the Philippines so the currency rate here is like 50 pesos is to one dollar, and that's how much we spend on every meal excluding rice. It limits our choices to veggies and a few slices of meat most of the time, and it helped me curb my overspending habit when it comes to food. It also helped us save a lot. You do not have to eat extravagant food in order to be healthy.

*Use processes when planning an outing. We all love going out, and that means shelling out some money. Planning your outing and sticking to a budget helps you enjoy the moment and affording yourself a relaxing day without going broke</comment>


Ask HN: Time to fix the online ticket space. What would you do? - <AUTHOR>

It's been an ongoing problem but these last few weeks have really focused my attention on it as a huge problem needing to be fixed.
Online ticket sales are absolutely broken. I'm not talking specific outlets, though they are broken for tons of other reasons, but the ability to resale tickets has been a huge pain as of late for many. Scalpers purchase their max tickets and turn around and put them up for sale at 10x the cost for concerts.
What really made me point this out now is this article on /.
http://apple.slashdot.org/story/13/04/25/2026214/wwdc-sells-out-in-2-minutes-ticket-on-ebay-45-minutes-later
What would be your solution here?
Mine would be simple - don't allow resale. Only allow the tickets purchased to be used by the person that originally purchased it. I can't help but think that applications like iOS' Passbook would be perfect for this. That way if you purchase a ticket, only YOU can use them. Even if you purchase many, then you have to be there to allow anyone entry.
I hate paying MORE for concerts these days but this solution would also provide an "insurance" at a nominal price that would allow a full refund if unused. Other sites already charge a ton for "service fees" so I'd happy purchase a ticket that only I could use and pay a little more to make sure I can get fully refunded if I don't go.
Thoughts? What's wrong with this solution? What would you do to fix this? <comment><USER2> > Only allow the tickets purchased to be used by the person that originally > purchased it.

The reason this method can't be used is because of a legal issue. Someone who buys a ticket has the right to resell it. Suppose after buying the ticket, they realize they can't attend -- should they be stuck with a ticket they can't resell?

Also, if reselling wasn't allowed, ticket agents would be driven out of business, and ticket agents vote.

> I'm not talking specific outlets ...

What is an "outlet" but a ticket reseller? If this idea were put into play, that reseller would be prevented by law from doing business.

Concert producers cooperate with, and depend on, resellers to increase the market for their product. So even the ticket's originators would object to the idea of disallowing resales, for a reason given below.

> ... this solution would also provide an "insurance" at a nominal price that > would allow a full refund if unused.

That's another objection to the idea. A concert producer would much prefer that the ticket be resold than to have to provide a refund as well as lose one attendee for each refunded ticket.

</comment><comment><USER3> It's probably the same few scalpers every time. You don't want to punish the average guy that changed plans and needs to resell once or twice.

If you had the data, it would be easy to spot these trends and catch the bad guys. We need the staff at the concerts to check ID and log the name of the person and the name on the ticket. Mismatch: flag the buyer and see if they've done it before.

</comment><comment><USER4> Isn't this a demand-supply problem? People tend to make profit (legal or illegal) by increasing selling price when demand is high. This might suck for buyers who can't afford it. But, that is pure economics.

Would you change the supply side of the equation or would you tinker with the transaction to fix this?

</comment><comment><USER5> If you mean competing with TicketMaster, etc, go read <http://lefsetz.com/wordpress/>

It turns out most of the acts scalp the tickets themselves for additional income.

</comment><comment><USER6> I have season tickets for the local sports teams. I don't really make money selling the tickets, but I wouldn't buy them if I couldn't sell or give away the tickets whenever I wanted.</comment>


An Open Letter to the Go Team About Try - <AUTHOR> https://www.ardanlabs.com/blog/2019/07/an-open-letter-to-the-go-team-about-try.html <comment><USER2> FWIW, I wrote a short response here: [https://twitter.com/_rsc/status/1146128393542492160](https://twitter.com/_rsc/status/1146128393542492160)

I want to flag especially that there is not, nor has there ever been, a plan to "push this through".

People consistently say error handling is problematic for them in Go. Overall I think people spend more time writing error checks than they should, and at the same time there are still too many mis-handled errors. We would like to see if we can find a way to make it both less work and more correct. Maybe we can, maybe we can't. The process is slow and needs to backtrack out of formerly-promising dead ends, and that's OK.

There's a very large amount of conversation right now around try, and that's good. Like I said in the tweets, community-wide discussions like this one are open source at its best.

<comment><USER3> I think "try" is a terrible name, because it overloads try/catch which is very common usage these days but it's nothing like that. It's basically a error checking macro, so give it a new name.

<comment><USER4> Rust had the try! macro before which is similar, the name is fine I think.

</comment></comment></comment><comment><USER5> _> Rob Pike gave a talk last year at the Go Sydney meetup where he talked about the Go 2 changes. In his talk, he suggested that the use of if err != nil in code bases is nowhere near as common as the vocal minority suggest._

This page shows the most common words found in a large corpus of open source Go code on GitHub:

[https://anvaka.github.io/common- words/#?lang=go](https://anvaka.github.io/common-words/#?lang=go)

The top four most common words are "err", "if", "return", "nil". These are each more common than "func" and "string" _combined_. It's hard to square Pike's comment with that evidence.

I don't know if the try proposal is a good one or not, but I think it's pretty clear that Go's original approach to error handling is quite verbose. Whether it _should_ be that verbose is an interesting question, but personally I think making the user repeat that _exact same boilerplate_ every time adds little value. If you want code that can fail to be visible, at least make the boilerplate shorter, which I guess the "try" proposal accomplishes.

<comment><USER6> Just goes to show how out of touch with established programming language research and practice the golang authors are. Now they're re-inventing exceptions, but badly.

It seems a lot of things in golang were done just for the sake of being different, with nothing to back it up.

<comment><USER7> > It seems a lot of things in golang were done just for the sake of being > different, with nothing to back it up.

Take an afternoon to go through the Go FAQ [0] (they answer why they don't have exceptions), design documents [1], including this fairly recent one [2] about error handling - they explicitly discuss exceptions and the pros / cons - and that's just what ended up in the design documents / FAQ, there's been at least ten years worth of discussion gone into that beforehand. Do some googling before making accusations like that please.

[0]: [https://golang.org/doc/faq#exceptions](https://golang.org/doc/faq#exceptions) [1]: [https://github.com/golang/go/wiki/DesignDocuments](https://github.com/golang/go/wiki/DesignDocuments), [https://github.com/golang/proposal](https://github.com/golang/proposal) [2]: [https://go.googlesource.com/proposal/+/master/design/go2draf...](https://go.googlesource.com/proposal/+/master/design/go2draft- error-handling-overview.md)

<comment><USER6> I'm aware of their rationales, what I'm saying is that they don't make sense and are dismissive, and have no studies at all to back them up.

It's there in the first link you posted for example, "we believe exceptions lead to convoluted code". Belief here is not sufficient, it must be conclusively shown that it's otherwise, especially given that _subjectively speaking_ it is possible in golang for errors to slip and not be handled at all (I saw it in real code bases), much much worse than any "convoluted" code that exceptions may result in (again it's very subjective - the way golang handles errors results in much longer code that's harder to follow).

</comment></comment></comment></comment><comment><USER8> I agree with blog author's sentiments. Go is a bit too imperative but that really aides in a team environment. Though the Golang's constructs are a bit bland (especially error handling) it actively prevents code to be too intelligent there by aiding readability I am able to work on the code I wrote 2 years ago with little difficulty in Golang and I can't make the same claim for other `leading` languages (though I assume full responsibility for what happened)

Edit: grammer and spelling

</comment><comment><USER9> Before commenting, please read the detailed design document [1] and see the discussion summary as of June 6 [2], the summary as of June 10 [3], and specifically the advice on staying focussed [4]. Your question or suggestion may have already been answered or made. Thanks — ATT: Robert Griesemer

\---

I like writing _"if err != nil { … }"_ so while I disagree with the proposal to add the error check function "try()" I will keep an open mind because I do not have the technical literacy as @griesemer or other people in the Go community to propose something better. I'll experiment with "try" a few times in personal projects, but I can see myself writing "if err != nil" for several years unless I find a more compelling reason to change, same reason why my team and I haven't adopted "go mod" despite having Go v1.12.6 (latest stable version as of today) in all our production servers.

[1] [https://github.com/golang/proposal/blob/master/design/32437-...](https://github.com/golang/proposal/blob/master/design/32437-try- builtin.md)

[2] [https://github.com/golang/go/issues/32437#issuecomment-49926...](https://github.com/golang/go/issues/32437#issuecomment-499261947)

[3] [https://github.com/golang/go/issues/32437#issuecomment-50061...](https://github.com/golang/go/issues/32437#issuecomment-500613160)

[4] [https://github.com/golang/go/issues/32437#issuecomment-50187...](https://github.com/golang/go/issues/32437#issuecomment-501878888)

<comment><USER10> > I like writing "if err != nil { … }"

That idiom was my biggest turn off in learning Go.

I would be 100x happier with "if not err {...}"

</comment></comment><comment><USER11> Bill helped me with my resume once in the Go slack channel. Great guy. I also happen to agree wholeheartedly that introducing try would be disastrous to the mostly consistent codebases Go is currently able to painlessly produce.

Personally I don't want error handling changed at all. It's very repetitive in it's current state, but clearer than in any other language I've used.

<comment><USER12> Eh, I feel like Go errors are a mess, personally. Though, I'm not sure how to solve them. Mind you, this is after ~5 years of use, so it's not from "an outsider" \- I hope, at least lol.

Most of blame for the mess is that the error interface throws away meaningful information. Then the caller is left mentally checking how to handle the error. Do I value check? Type cast? String check? Does the library expose a function to check, or do I do it myself? Can I get stack traces in some cases without introducing a production cost?

I'm not sure if Go needs a different type of error interface (ie diff methods), or if it needs Generics to solve this properly in my view. But, I just know I've hated the experience.

After I switched to Rust it all felt so familiar, and yet so different. I believe Rust and Go share error patterns. Yet in Rust I'm never left wondering what an error is, what I should do with it, how I check for specific types. This is largely due to awesome enum support and of course generics. Does Go need this feature set to "fix" my complaints with errors? Probably not.. but I do think it needs something.

Though I will agree, I don't think the `if err != nil` is fundamentally the problem with Go's errors, at all. Sure, the UX could be improved, but that's another story all together imo.

<comment><USER13> Honest question as a non Go user: how would generics (from a C# perspective) help? I assume that Go generics would be analogous those in C#.

Edit: spelling, genetics to generics.

<comment><USER14> Rust has a wrapper type `Result<ReturnType, ErrorType>`[0] that essentially works the same was as Go's `return value, err` idiom, but is safer because the type is defined so that you can't access the returned value unless you also handle the error condition, and it can have a convenience syntax for chaining since it is a dedicated unambiguous type. The compiler also specifically warns you about unused `Result`s, to avoid unhandled errors, and the API is structured so that nonsensical states such as `(nil, nil)` or `(value (!= nil), error (!= nil))` are impossible (unless specifically opted into).

Without generics you would have to either throw away the type information, reimplement a `Result` type for every value type, or copy/paste the implementation at each usage site (the common Go pattern).

Go's support for multiple returns itself is also a hack around the lack of support for tuples (which would be trivial to implement if you had generics).

[0]: [https://doc.rust-lang.org/std/result/enum.Result.html](https://doc.rust- lang.org/std/result/enum.Result.html)

<comment><USER15> _> a hack around the lack of support for tuples (which would be trivial to implement if you had generics)_

To a first approximation, the purpose of Go is to stop every codebase from reinventing its own tuples or Result<> type.

Go does have generics, the Go compiler could add a chaining syntax for trailing err interfaces (like rust ? / try!) without needing to allow user- defined generic types.

<comment><USER16> I hope it's not literally to prevent people reinventing these simple data structures.

The ecosystem exerts a lot of pressure on developers to not reinvent fundamental things, in Haskell I practically never reach for a StrictTuple or StrictEither even when I'd like strictness specifically because they are clunkier and less well integrated with other libraries.

Scala is the only language that comes to mind with this issue (scalaz vs Cats) and my impression is that even they have mostly converged.

I would say Go has much stronger idioms than either of these languages, and wouldn't need to be afraid of people inventing their own fundamental types provided they're included in the standard library.

<comment><USER17> > Scala is the only language that comes to mind with [the issue of needlessly > reinvented fundamentals]

C/C++ is another example. There are a plethora of string types mostly tied to which base set of libraries you're using. If you're using the C++ stdlib, you have std::string. But if you're using Qt, you're using QByteArray and QString instead. And probably similar for GLib/GTK.

(Does std::string even have any encoding support yet? When I last used it, it was just a string of bytes without any encoding awareness.)

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> > biased because only those who had a problem submitted proposals and this > leaves out all of the developers who don't consider error handling in Go > needs to be better

It's probably also biased due to the people who gave up on Go completely because they saw it as a sufficiently major issue and/or had little faith in Go ever improving (I can't exactly put a finger on it, but a lot of the decisions in Go seem to be backed by "... and if you don't like our approach, you're WRONG").

<comment><USER19> > "if you don't like our approach, you're WRONG"

This was also my experience interacting with the Golang team while working at Google.

</comment></comment><comment><USER20> I don't write a lot of Go but I have fuzzed a reasonable amount of it. One of the most common types of bugs I encounter are slice out-of-bounds errors. In Go, this invariably leads to immediate program termination (panic). Especially parsers of serialized data received over the wire (like protobufs) are susceptible to slice OOB bugs because the programmer needs to reason about lengths, offsets and integer wraparounds, and this is often hard to get exactly right. Due to the combination of parsing untrusted data, the likelihood of bugs and flat-out crashes if there is a bug, network-facing Go software is especially prone to very low-effort denial-of-service attacks.

Python and Java got this right: everything throws an exception, including out- of-bounds access (IndexError, ArrayIndexOutOfBounds), so by wrapping your whole application in a try/except block you can eliminate a whole class of otherwise fatal errors.

Unless I missed something, the upcoming change isn't going to alter the handling of OOB's, which seems like a missed opportunity because a fully- fledged try/catch mechanism could effectively defuse many bugs.

<comment><USER8> In Java land checked exceptions are considered to be an anti pattern for sometime. If I remember correctly one of the major change in Hibernate ORM 3.0 was converting checked exceptions to runtime equivalents (ie, caller is free to disregard the exception) (this happened 10-12 yrs ago). Coming back to Golang, you get the same behaviour if you are not checking `error is nil` condition

<comment><USER21> When Java finally got generics, it didn't add any support for generic sum types of checked exceptions.

      stream.map(f).collect(…)

should obviously be able to throw anything f could throw. But instead f is forced to wrap every checked exception, and so pretty much everyone has given up and started declaring new exceptions as unchecked.

</comment></comment></comment><comment><USER22> I find the logic the article uses to make its point a bit handwavy, or you could even say "wrong". If the language specification required the first line to start FIRST and then every subsequent line in each file start with AND THEN, so that this:

       package main

       import (
        "fmt"
        "net/http"
       )

       func main() {
        http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
         fmt.Fprintf(w, "Hello, you've requested: %s\n", r.URL.Path)
        })

        http.ListenAndServe(":80", nil)
       }

becomes

       FIRST package main
       AND THEN
       AND THEN import (
       AND THEN  "fmt"
       AND THEN  "net/http"
       AND THEN )
       AND THEN
       AND THEN func main() {
       AND THEN  http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
       AND THEN   fmt.Fprintf(w, "Hello, you've requested: %s\n", r.URL.Path)
       AND THEN  })
       AND THEN
       AND THEN  http.ListenAndServe(":80", nil)
       AND THEN }

there is a very good chance it would not make it into "the biggest challenge you personally face using Go today." Because it's not a challenge. It's stupid, but not a challenge.

So just because the verbose incantation

       if err != nil {
           return err
       }

or other issues, could be thought of as very similar to AND THEN, it doesn't mean that this is the biggest challenge someone personally faces. it could be stupid, but you get used to it.

so it depends on the wording of the question. Basically the real question isn't how big of a pain point it is. It's how much it could be fixed.

my specification for the formatting of the language would be hugely improved by removing the AND THEN line from each line of the code. It's kind of ugly.

<comment><USER18> It would also probably not come up in surveys, because the only people using the language would be the ones who are OK with it - others would simply take a look at it, conclude that having a pointless "AND THEN" everywhere is just too ugly, and move to a language that made better choices.

</comment></comment><comment><USER23> I've heard people complain about the explicit error handling in go, but that is mostly because they are coming from other languages such as java which have inferior error handling that lets them write 'neater' code, but which generally results in less than robust error handling.

Picking on Java, it has checked exceptions, unchecked exceptions, and errors. It's basically a minefield of complexity leading to undefined behavior and/or misbehaving error legs. I can't tell you how many times I've seen InterruptedException mishandled, Throwable (which includes VirtualMachineError) caught with no appropriate handling (quick - what is the appropriate handling of a VirtualMachineError?), or exceptions allowed to wildly propagate.

<comment><USER24> > java which have inferior error handling that lets them write 'neater' code, > but which generally results in less than robust error handling

Wowza, that's a strong stance.

Look, I'm a fan of Go and Java is definitely aged in a lot of places but this is one of the most bizarre claims I've seen. Criticism of Java's exceptions come from both sides, some people who hate unchecked exceptions so "anything can throw" (same reason C++ camp often avoids exceptions); or that checked exceptions are stupid since you can't meaningfully fix Interruptions or IOExceptions so it's verbose and meaningless to force local catches; they almost always need a rethrow. _Both_ of these criticism are fair because in the end they both make sense sometimes and thus are misused for one another occasionally. We'd all like one answer consistently applied but we don't have it here.

Error codes formalized as a part of an API have their place but I find their utility is much more niche than people give them credit for. Why should I decode error codes when a String and a Trace will do? Hint: only when errors have formal semantics such as within a protocol. How I handle the error is partially decided by spec.

But to say that in comparison to Go? Go has its normal err mechanism and panic/recover. err is a huge step up from C style errno/manual checking. In practice, Go's err is embarrassingly used just like a checked exceptions: observe and ignore/log or propagate. You end up just unwinding the stack manually, losing the trace, maybe adding context occasionally, like 70% of the time. You handle it where it's meant to eventually, sure.

Like everybody does, when it is done right.

panic/recover is just unchecked exceptions all over again anyway. They seem to be treated as voodoo idiomatically, sure, but they're there.

Go is a great language that brought some really good language runtime features together in a pretty tidy package. Besides maybe defer, which is pretty clean, error handling just isn't a part of the language that got the polish that other parts of the language got on the first pass.

</comment></comment><comment><USER25> This blog pretty well sums up my feelings about the try method. It just doesn't really seem necessary. I'm sure it would help in some of my code, but importantly not _all_ of my code, and if a construct is only available some of the time, I will inevitably favor the doing the same way _all_ of the time rather than adding a little syntactic sugar every now and then.

I'd much rather see some kind of genetics support get well integrated, given that's a problem I run into fairly often.

<comment><USER26> Agreed! (Though I'm assuming you meant to type generics. However, I'd love a library to alter genetics)

<comment><USER25> Hahah this is what I get for typing on my phone.

</comment></comment></comment><comment><USER27> Go errors prioritize explicitness, in declaration of what functions might fail, and in handling of those failures.

It seems like a mistake to add a language feature that works against explicit handling. At minimum, the endorsement of returning the raw error reduces clarity on what "good error handling code" should look like.

<comment><USER28> agree totally.

I'd prefer to see an official errors.Wrap function instead of "try", for the reasons you cite.

(shout out to Dave Cheney's excellent "pkg/errors" implementation of error wrapping)

</comment></comment><comment><USER29> > effort to understand exactly what those 5% of Go developers meant when they > said they wanted improved error handling

> If you look closely, error handling is not even in the top 3 challenges > faced by developers, it's number 5

Nonono, that's not what those numbers mean. 5% said it was their absolute biggest problem. For all you know it could be the #2 problem of 90%.

</comment><comment><USER30> This will be legal with the proposed `try` statement [0]:

      info := try(try(os.Open(file)).Stat())

I'm worried about nested versions of this and having to unpack them when reading code, which at the current moment has a much easier imperative block structure.

[0] [https://github.com/golang/proposal/blob/master/design/32437-...](https://github.com/golang/proposal/blob/master/design/32437-try- builtin.md#properties-of-the-proposed-design)

<comment><USER31> I've never seen this come up as an issue when reading Rust, which has the same feature being proposed for Go (and then later shortened it to just a single character, ?).

<comment><USER29> ? is a big improvement over try specifically because you _don 't_ have to unpack nested statements. Everything flows left to right.

</comment></comment></comment><comment><USER32> I was never a fan of try. It's too magical and breaks the flow.

Far better to use something more explicit and controllable:

        f, err := os.Open(filename) onerr return 0, err

which is just syntactic sugar for:

        f, err := os.Open(filename)
        if err != nil {
            return 0, err
        }

also:

        err := DoSomething() onerr {
            fmt.PrintF("We got error %v\n", err)
            return 0, err
        }

</comment><comment><USER33> The way errors are handled in go feels like the people were thinking hard "let's not repeat the horror of C++ exceptions" and are ok with ugly warts so long as they're not uglier than exceptions...

It's clear that there's way too much boilerplate in go procedures that deal with error handling by systematically bailing and passing the failure upstack...

But the most confusing thing to me about try() is that, although it's shaped like a function, it actually returns from the current scope on error. It's dangerous syntactic sugar IMO to make this one function-call-like feature not behave like an actual function call...

<comment><USER34> Too late, Go already has panic(), which is a magical function that unwinds the stack.

<comment><USER33> !

So it's legal to write something like...

       panic(panic())

or

       a := try(try(f()))

...?

<comment><USER34> panic() doesn't have a return value, so no. But try() has.

</comment></comment></comment></comment><comment><USER35> I wonder if Go just needs syntactic sugar that's similar to the RETURN_IF_ERROR that's common in Google C++ code (for example, in protobuf: [https://github.com/protocolbuffers/protobuf/blob/master/src/...](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/stubs/status_macros.h#L49))

</comment><comment><USER36> Does anyone have a link to the "try" proposal the author is advocating against? It's not clearly linked in the article.

<comment><USER37> [https://github.com/golang/go/issues/32437](https://github.com/golang/go/issues/32437)

</comment></comment><comment><USER38> Try aka ASSIGN_OR_RETURN

</comment><comment><USER39> All the try(), catch(), and onerr proposal are ugly patchworks. All I need is to be able to skip the != nil and just be able to write: if err { ... }

</comment><comment><USER40> I'm glad this post (and others) are sounding the alarm.

Go's greatness could very easily be destroyed by a small number of missteps like this one.

I'm wishing for the absolute rule of the curmudgeony quadrumvirate like the one that designed Go. This feature-bike-shedding hungry mob is proof of the problem with democracies.

And when it comes to programming languages (unlike societies) the the trade- offs for a democracy are not worth the price. Go should (almost) completely ignore the crowd on design issues. It should have changes made that a small cabal of experts unanimously agree with.

</comment><comment><USER41> This proposal really seem to rile up the community, can't it be shelved and revised until let's say v2.4 or something?

<comment><USER18> Of course it can. It can also be shelved indefinitely or not done, but at some point, it's time to make a decision. Opponents of this would of course prefer it to be "shelved" instead.

</comment></comment><comment><USER42> I wouldn't like to see a change to error handling, I would like to see generics added (in the form that was described in the Sydney talk).

Maybe a stack trace would be nice in the errors, though

</comment><comment><USER43> Stop fighting it embrace it. Error checking in go is one of my fav part of go.

</comment><comment><USER44> I am not a Go programmer, but:

The article suggests that try() isn't solving a big problem. If I were a Go programmer, I think I would want a bigger change, specifically, a proper sum type for errors. In Go, the convention is to return a result _and_ an error despite the fact that essentially every function that can return an error wants to return a result _or_ an error. This results in complexities in the proposal about what the result should be when try() causes an error return. The sensible answer is that there should not be a result.

The way that Rust (and Haskell and many other languages) do so much better than Go has little to do with fancy ? operators. It's that the return type makes sense.

Of course, sum types without genetics would be odd, but I don't see how this would stop Go — a special case specifically for "such-and-such type or error" seems consistent with the Go typing philosophy.

<comment><USER24> I think it's funny that you mention a bigger change but sum-types are 80% of what Go already has here. While it's true that it solves the ambiguity issue of representing `Either Result or an Error But Not Both` instead of the `Result or Error or Both`; that doesn't solve the issue that anyone actually has, which is that most errors are handled with

      if err != Nil {
        return err;
      }

_after every other line_ sometimes. It's verbose, manual, and doing the helpful thing like adding context for the error is repetitive and often omitted. As I've mentioned elsewhere, you essentially want an exception system.

Some care still needs to be taken with how other language features interact with it. You'll probably want a sum-type-y way to catch exceptions as an expression eventually. What happens if exceptions are thrown from functions in defers, etc. But unlike more FP languages where error propagation is much easier in a soup of composed functions, Go is much more Java/C#-like. Most functions have much more important names and meaning which make stacktraces much more valuable.</comment></comment>


Planting GMOs kills so many bugs that it helps non-GMO crops - <AUTHOR> https://arstechnica.com/science/2018/03/planting-gmos-kills-so-many-bugs-that-it-helps-non-gmo-crops/? <comment><USER2> Good example of side effects that could and should, but often aren't, predicted when modeling the impact of a modification. Not harping on GMOs, I think they're great, I'm just saying I hope they consider externalities responsibly. In this particular case, the externalities seem to be a net positive (unless you are a bug).

<comment><USER3> > (unless you are a bug).

Or something that depends on the bug.</comment></comment>


A Robust, Reconfigurable Atomic Memory Service for Dynamic Networks - <AUTHOR> http://www.systemswemake.com/papers/rambo

<comment><USER2> FYI the embedded viewer just shows the Google Docs landing page for me.</comment>