Hacker Newsnew | past | comments | ask | show | jobs | submit | npinguy's commentslogin

> It reminds me of the made-up but often used story of terrified audiences running for the exits upon watching a film of a train for the first time.

The cultural recontextualization of stories like this in my lifetime has been one of the most fascinating aspects of our modern world for me.

Of course, as I get older, I've seen my own stories and stories about events I participated in get told, re-told, and twisted and exaggerated without absolutely any malice. We also all see how people misrepresent news stories, social policies, and scientific studies (with various degrees of malice). So I think I know almost exactly how the Film of Train anecdote happened.

1. Theater owner starts showing Train film. Stands outside and yells "Come inside and see the wonderous train show. This new 'cinema' is so real that audiences have been reportedly running for the exits in terror!"

2. It's an obvious exaggeration and a joke. Passerbys laugh, but are intrigued nonetheless.

3. Someone writes a newspaper story about the cinema and the train film. Includes the quote as directly attributed to the theater owner. Everyone reading is aware of the context and the situation and the implicit tone, and chuckles appropriately.

4. Story gets picked up in another newspaper but without the context and removes the quote and instead represents it as a factual retelling of what happened.

5. Years later, someone writing a book uses the newspaper as a primary source, and then a cascade of books repeat and propagate the "fact".

Perfectly reasonable sequence of events. But here's where things get even more interesting to me.

There are *dozens* of similar stories that we've all heard and took as gospel growing up that required one person to stop, ask "Wait, does this really hold up to scrutiny?" and the whole house of cards comes crashing down. I'm talking about the "NASA spent $10M to design a space pen, the russians used a pencil", "Water flushes in the opposite direction in the southern hemisphere", and the like.

But why did it only happen just now? What prevented people from being more introspective and curious about these subjects 10, 20, 30 years ago? I guess the answer is we needed the Internet to hit a certain critical mass for enough people with sense to be able to reach the rest of us, but I don't know.


> What prevented people from being more introspective and curious about these subjects 10, 20, 30 years ago?

Perhaps we should be asking, what subjects are we failing to be introspective about now, that will fall into this category 10, 20, 30 years in the future?


> Do not try and compare an animal to a historically tragic event to justify word policing. Your use of tragedies to justify your woke word policing is quite frankly disgusting.

deanCommie was trying to get you to see that SLAVERY was also a historically tragic event that people are reminded of when they see terminology like master/slave.

> Chaos monkey sounds completely fine and I can't see how any sane non-racist person would associate that with a black person.

They weren't trying to say that. This whole discussion is master/slave. This is precisely the point - chaos monkey is a fine neutral term that describes what is needed without any negative connotations. "Concentration camp guard" isn't.

Primary/replica is a fine neutral term. "Master/slave" aren't.

Honestly, your outrage about the comparison to concentration camps exactly proves the point that language matters regardless of intent.


Let's start from 80 hours a week spent at work. Red flag #1. Don't know why you would assume that's necessary

3.5 hours/week showering. Red flag #2. Even if you shower every single day, if you're spending 30 minutes in the shower each time you might as well call it a hobby. Unless you've got long luxurious hair, you should be able to get everything done in 10 minutes.

10 hours commuting, so 1 hour each way? #3 How much do you value your time? Clearly if you can't think of a hobby, not very much. If you did, you'd pay extra to not waste 2 hours every day wasted. But wait...why are you wasting that time? Can you read? Listen to audio books? Work on a side project? Even day dream and think? If you have to drive, can you switch from driving to motorcycling, and make that a hobby?

It sounds like you WANT to throw yourself into work, and spend all your energy and time into it as an excuse for lacking the ability to become a fully developed multi-faceted human being. And that is on you, not on your employer.


He used the word "shower", but I think he meant the time it takes to look respectable - so please add drying after shower, shaving, toilet trip(s), dressing, etc.


I have long, luxurious hair. Hair only stays long and luxurious if you don't wash it daily. My showers go from 5 minutes to 10-15 minutes on hair wash days.


The same reason that the Civil Rights act had to be passed in the courts and the first students in integrated schools in the south had to be marched in with armed guard.

"Democracy" is frequently used interchangeably with freedom, but never underestimate the power of a close-minded majority to rule with tyranny and impose their will and discrimination on a minority - racial, sexually-orientatated, or otherwise.


"the Civil Rights act had to be passed in the courts"

What?



OP should have written: "The same reason that the Civil Rights act had to be UPHELD in the courts".


Because it's bizarre and stands out. The clarifying sentence of marrying people that live elsewhere etc screams of "the lady doth protest too much". There's nothing wrong with saying "Over time, and over the natural turnover that happens at all companies, none of the original Wasabi designers are no longer working at FogBugz". Sure, some snarky people will make the comment "Oh yeah, I bet they left BECAUSE of Wasabi", but most will ignore them.

By completely negating the possibility that any of those people left for any reasons not involving family, it actually seems to INCREASE the probability that Wasabi was more unpopular within FogCreek than Joel would prefer to admit.


Do you know anyone at Fog Creek, or even anyone who has ever worked there? Did they tell you something that would lead you to believe that a blogger for Fog Creek would, completely unprompted and with no real need, make up stories about why people left?

Or could I just as easily argue, with the same total lack of grounding, that you're a secret shill for Atlassian trying to poison the well? (You aren't, of course, but you take my meaning.)


Good news, I actually do know everyone who was part of the original build of Wasabi! None of them left because of the language. I think this accounts for everyone who was there at the time:

1. Original author left because his wife was going to medical school out-of-country and Fog Creek didn't allow remote work at the time.

2. Second author left because his wife was going to medical school out-of-state and Fog Creek didn't allow remote work at the time (see a pattern?). Later came back because Fog Creek offered remote work. Went on to author the blog post we're talking about.

3. Developer left to go work on Stack Exchange (me!)

4. Developer left to go make the world a better place at Khan Academy

5. 2x developer left to go work on Trello

I think that was all of us. People move on in the course of 5+ years. Turns out most of those reasons don't have to do with programming language.

FWIW, I think Wasabi was a bad decision and I'm not going to defend it. But I really don't like these massive assumptions about people's motivations for leaving.


Thank you very much for this comment.

Can I guess at why you think it was a bad decision?

(a) Too incremental to be worth it, given where the .NET ecosystem was heading

(b) FC couldn't commit the resources required to adequately support a whole language, and it's better to commit to a lower common denominator than limp with a poorly supported language

(c) If you're going to create an additional obstacle to on-ramping employees, it had better be something every project in the company takes advantage of --- like, even if you had built FogBugz in OCaml, that would be a problem since the company is not designed to take advantage of OCaml.

(d) Unless you're getting a truly transformative advantage from a custom language, it's not worth it to be out of a "Google your way out of most problems" mainstream sweet spot

(e) No matter how good the language is, using a different language makes you incompatible with toolchain, so edit/test/debug cycles are needlessly painful

I obviously have no idea if Wasabi was a good decision or not, but a workplace where people are allowed to deploy basic computer science to solve problems is (sadly) an attractive stand-out to me.


So, I'm not David, so I'm not going to pretend to know what his thoughts are, but I'll say that I've always had really mixed feelings about Wasabi.

Let me start by saying that Wasabi as a strategic move was brilliant. If David disagrees there, I'm a bit surprised: FogBugz represented an awful lot of battle-tested low-bug code, and finding a way to preserve it, instead of rewriting it, made one hell of a lot of sense. I'm with you that the general thoughts in this forum that we'd have to be insane to write a compiler are misguided. Wasabi let us cleanly move from VScript and ASP 3 to .NET without doing a full rewrite, and I'd be proud to work at a place that would make the same decision in the same context with full hindsight today.

That said, I think Wasabi made two technical decisions that I disagreed with at the time and still disagree in with in retrospect. First, Wasabi was designed to be cross-platform, but targeted .NET prior to Microsoft open-sourcing everything and Mono actually being a sane server target. At the time, I thought Wasabi should've targeted the JVM, and I still think in retrospect that would've been a much better business decision. I really prefer .NET over Java in general, but I know that it caused us an unbelievable amount of pain back in the day on Unix systems, and I think we could've avoided most of that by targeting the JVM instead. Instead, a significant portion of "Wasabi" work was actually spent maintaining our own fork of Mono that was customized to run FogBugz.

Second, Wasabi worked by compiling to C# as an intermediary language. There was a actually an attempt to go straight to IL early on, but it was rejected by most of the team as being a more dangerous option, in the sense that maybe three people on staff spoke IL, whereas pretty much everyone could read C#. I also think this was a mistake: the C# code was not human-readable, made debugging more complicated (VS.NET had something similar to source maps at the time, so it wasn't impossible, but it was very indirect and quirky for reasons I can get into if people are curious), and that decision meant that Wasabi had all of the limitations both of its own compiler, and of Microsoft's C# compiler. IMHO, these limitations are a big part of why the ultimate move away from Wasabi was even necessary in the first place, since they increased both the maintenance and developer burden.

So from my own perspective, I think that Wasabi was a mistake in that, if we were going to go to C#, we should've just got the translation good enough to really go to C# and then ditch Wasabi; and if we weren't, we should've actually owned what we were doing and written a genuine direct-to-IL compiler so we'd have more control over the experience, instead of going through C#. But I still really do genuinely believe that our going to Wasabi was a brilliant strategic decision, and I think Fog Creek would have suffered immeasurably had we not done it.


People wonder why I like HN so much. Maybe it's because a comment like this is buried in a thread and you have to dig for it. Thank you!


I'm particularly interested in your thoughts on Wasabi compiling to C# rather than CIL. What characteristics of Wasabi led to the C# output being suboptimal for human reading and editing? If a compiler is going to output human-readable code, are there any general design pitfalls to avoid?


To add to Ted's comment, the main mistake we made in generating readable C# from the start was using `System.CodeDom` as our code generator, which explicitly does NOT care how readable your output is.

A better idea would have been to hand-code the generator, though of course that would have been a lot of string manipulation as well as a little extra effort.

Roslyn solves both of those issues for us, but it didn't exist until very recently.


Beyond what tedu and krallja pointed out, the debugging required inserting tons of #line markers in the C# output. But a single line of Wasabi could map to multiple lines of C#, making the definition of stepping ridiculous. Throw in that Wasabi necessarily grandfathered ASP globals that C# lacked and you also had fun variable display.


The semantics of wasabi (VB) and c# are slightly different. A fair amount of the code was actually the result of various code generators. It dumped everything in one giant file (delimited by #file markers, though). Nothing intractable, but nothing high priority.


Having done something similar, but entirely different, several times, I'm surprised you didn't choose to slowly refactor the code to be more and more native C# over time. iYou start with 100% Wasabi / 0% C# and slowly work up the native C# parts, in code units, until you reach a level sufficiently high to feel confident to do a final push to switch entirely to C#.

(In my experience, you need to build up an inter-op layer first to make working in C# somewhat sane, but it's usually not hard to identify the necessary helper modules needed. Having the .NET runtime actually is a boon here since the IL is designed for inter-language inter-op.)


Starting with version 7, a lot of new development was actually done as plugins, in c#.


Quick question:

Why did you find yourselves maintaining a fork of Mono (versus fixing upstream)? Was it something like forking, although being problematic, had lower impedance than doing the necessary rituals for getting your changes accepted upstream?


You can't exactly tell customers to go check out the latest subversion head and compile it themselves. Changes were pushed upstream, but that doesn't push them to customers. Neither could we ship nightly builds, because who knows what changes get introduced? So we had a fixed release with a pile of patches on top of it.


I think there's a useful lesson here about precision in writing. _Why_ the Fog Creek developers left isn't central to the essay's main point, and it's not interesting in itself. But the author did include it, so clearly he thought it was relevant somehow, but why? One salient hypothesis, in this context, is definitely "they left because of Wasabi".

Well, I don't think they actually did leave because of Wasabi; the chain of reasoning I described above isn't very sound. But it's easy and obvious, and the author could have avoided it by doing a little less.


> One salient hypothesis, in this context, is definitely "they left because of Wasabi".

Indeed. And then the author goes on to explain the actual reason, so you don't need to guess.


Sure. As I said, I don't think skepticism is _correct_ here. But a critical reader will always be asking themselves, "why did they write it that particular way?", so as an author you have to continually ask yourself the same question.


I do not know anyone who has (or does) work at FogCreek.

But I can imagine a scenario where an employee leaves due to tech stack woes. The employee may not want to burn bridges during their exit interview by saying, "I'm leaving because this tech stack sucks: it's affecting my long-term career progression (no other companies use Wasabi); management is too slow to adapt despite our repeated kvetching; the 1 full-time guy who knows the language is overworked and doesn't have time for proper training." Instead, the employee just says, "I'm leaving for personal reasons" and everything is wrapped up nicely.

Edit: Glad to hear from other commenter that this wasn't the case at FogCreek. I have known people to leave jobs due to tech stack woes; they didn't tell management the real reasons why the left.


Direct quote:

"The people who wrote the original Wasabi compiler moved on for one reason or another. Some married partners who lived elsewhere; others went over to work on other products from Fog Creek."

Unless I'm mistaken, this was all that was written about the reasons people left, which to me does not seem very "bizarre". Sure, he could have included "... and some left for other companies" but there's a difference between omitting the obvious and saying something like:

"Let it be known that all the ones who were truly good programmers, and by extension, real human beings! Only the best stayed at Wasabi. No one who was a good employee left for anything other than a personal reason. No one!"


The ability to do something does not hold any weight with the people you're trying to convince. "Oh sure, Apple can revoke my access time, but they never would!"

It's the same thing as "Oh I'm sure the government COULD access all my data, but why would they want to?"

Region-locking affects more people than you might think, just not with DVDs anymore. Most of the world using reddit/hackernews/the internet is constantly faced with the frustration of clicking on a youtube link and seeing the copyright notice that says the content is restricted to US-only.


The US gets that, too. We get it a bit less because so much is produced here; but I've definitely had my share of "Sorry, the owner of this video has not made it available in your region" notices.

It would be nice if it told me which regions were allowed, so I knew which VPN I should use :P


Off-topic question: Why do people insist on calling The Hoover Dam "one of the top engineering marvels".

Surely, a dam that doesn't even make it into the top-25 tallest dams in the world, and is 57th in the world in power generation is not that impressive? http://en.wikipedia.org/wiki/List_of_tallest_dams_in_the_wor... http://en.wikipedia.org/wiki/List_of_largest_hydroelectric_p...


There's always a critic.

I think it's important when considering lists like the ones you've linked to examine the dates these structures were built. For its time, the Hoover Dam was the largest in the world, but isn't simply the dam itself that represents an impressive feat of engineering. The work that went into diverting the Colorado River was (and still is) probably one of the most remarkable efforts undertaken, with the likely exception of the Three Gorges Dam. Either way, it's important to remember that this was a structure started in the 1930s. The age, materials available, the material science known at that time, and so forth are the reasons structures remain important samples of architectural engineering long after they've been eclipsed by more modern developments. Hence why it's difficult to tell if you're genuinely curious or simply levying unwarranted criticism against categorizing the Hoover Dam as a "marvel."

In other words, it's in our nature, for whatever reason, to continue building structures that grow ever larger, require greater understanding of materials--better materials, too--and shadow efforts of the past with new, more impressive, modern designs. However, that doesn't supplant those past efforts simply because they've been outdone. Otherwise, we wouldn't still consider the Great Wall of China one of the world's wonders (which in spite of our present technology still remains an incredible structure mostly unsurpassed by modern efforts).

You could also examine other answers to this same question if you don't find my response convincing [1].

[1] https://www.google.com/search?q=why+is+hoove+dam+an+engineer...


I think "of its time" is probably left out of that top engineering marvels quote. Look at what else was achieved by 1939 when they finished all the major construction.


Do you consider the great pyramids to not be an engineering marvel because it doesn't make the list of the tallest 1000 buildings in the world?


He also authored one of the two competing standards for JSON: http://tools.ietf.org/html/rfc7159


They're really not competing at this point. 7159 is the one spec to rule them all. ECMA-404 (which was kind of silly to start with[0]) isn't really relevant to most developers anymore.

ECMA-262 even explicitly uses 7159's predecessor (4627) with two exceptions[1], one of which is the top-level compatibility headache 7159 fixed, and the other just requires the API to disregard the "MAY" in section 4.

[0] https://www.tbray.org/ongoing/When/201x/2014/03/05/RFC7159-J...

[1] http://www.ecma-international.org/ecma-262/5.1/#sec-15.12


It's kind of how people are scared of dying in plane crashes but not in car crashes - the illusion of control. One easily imagines doing something to avoid a car death but not a plane one.

I think the same applies here: Death by starvation feels easier to avoid to a layman wilderness expert: forage more, hunt effectively, conserve supplies better, etc.

But death via an obscure chemical even while in possession of a book on edible seeds...that's scary and much more likely to give one reservations about their confidence.


Your comparison is bang on, except that's the point. Amazon isn't trying to be Ikea. It is absolutely trying to provide the building blocks for small companies and large to use their cloud platform in a very foundational manner. Yes, the onboarding cost may be high, but Amazon doesn't mind if customers end up using Heroku or EngineYard instead - they are customers too.

AWS is a lot like Linux that way: Deeply challenging initial learning curve, but the only thing worth considering for serious mission critical architecture. Stability and scalability does come at the cost of user-friendliness.


Are you saying there's a security and scalability to Amazon over Google Apps? People still make that argument about in house vs hosted, but hosted vs hosted of two major providers is new to me.


I don't know about security and scalability, but from what I read, it seems that Amazon gives you fine grain control and AD integration which is nice. Also, customer support is one area where AWS is better than Google in my opinion. YMMV.


Amazon's customer service basically exists where Google's doesn't.

People often don't realize what a chasm of difference that is.

It doesn't help Google any that Amazon's customer service is _great_.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: