18 ms·

Killing Off Wasabi

309 points by GarethX 11y ago

jim_greco 11y ago
A company should never build a compiler, database, or operating system if it is not their primary business.
- wiredfool 11y ago
  Or source control.
  - ohitsdom 11y ago
    Or chat tool, or bug tracker, or... The list goes on. Basically, focus on your core business. If you spend more than ~10% of your time building infrastructure tools, someone else probably does it better, for cheaper.
- ygra 11y ago
  As someone working on a compiler which is not a primary business of this company I disagree. Our main product is a large library with quite a lot man-years of work put into it that we offer on lots of different platforms and frameworks – for the most part with near-identical API and capabilities. Compiling the source into different languages rather than rewriting everything is a very valid approach. In our case almost all bugfixes and new features can be merged directly into the other products and work (the exception being the glue parts to the respective platform/framework). Being able to precisely control the output and thus guarantee API stability is a major factor in developing this in-house, especially as most converters only concern themselves with replicating the visible behaviour of a complete application.
  - beambot 11y ago
    If you license the library, why not directly cross-compile it (using existing compilers) and then just write wrappers to expose it in the target languages?
- kyllo 11y ago
  I think it's perfectly legitimate for a company to build those things when it's not their core business, provided that A. They hire people who are legitimate experts and give them free reign to work on it, and B. They open-source it. A lot of quality compilers and databases have come from software companies whose primary business is neither a compiler nor a database.
- codemac 11y ago
  I disagree, because there are SO many examples of companies and products that do this. Basically every data storage company, every networking company, every database company (meaning they wrote the OS).. Not to mention wasabi is a transpiler! It took VB-ish stuff and turned it into a few target languages. This is senior year undergrad complexity that they used for 10 years. The negativity on this post is astounding.
  - krallja 11y ago
    Writing a compiler sounds scary to some people. It's not scary. The only compilers training I have is a senior-year undergraduate course, and quite a lot of that was learning all the different ways to write parsers. Wasabi uses a LL(k) recursive descent parser, and you don't have to know what that means to be able to work on it. I've never even read the Dragon book; we used Cooper & Torczon "Engineering a Compiler" instead.
- braythwayt 11y ago
  I think you're close. A company should never do secondary business X if their proprietary take on X does not contribute to their value proposition in a way that external solutions cannot provide. At one time, for example, ice companies did their own deliveries because they needed special hore-drawn carriages to keep the ice cold.
- jfb 11y ago
  This is silly. If you make a reasoned decision, taking into account your specific circumstances and the projected changes to come over the midterm, and you decide to do this, well, why not? Should Google not have built go? Should Jane Street not have built core? Should Facebook not have built their suite of tools? I'm comfortable saying that the super smart people who advocated for those projects (among numerous others) had a pretty good case to make.
  - jim_greco 11y ago
    Why not? Because it creates a maintenance nightmare and if it's not your core business that means it will never be a priority. Using Google and Facebook as a counter-example is silly. These are $250B+ companies and these tools are a significant part of their business.
mwcampbell 11y ago
A lot of people criticize Fog Creek for writing their own compiler, but I think it's a good example of working smarter rather than harder to solve a problem they had at the time. I think that companies which apply sheer brute force to rewrite the same app in Objective-C and Java to target the popular mobile platforms could learn from this. I wonder to what extent the generated C# code depends on C#'s dynamic typing option. I ask because the original VBScript was certainly dynamically typed. So by the end, to what extent was Wasabi statically typed, through explicit type declarations or type inference? And how much did the compiler have to rely on naming conventions such as Hungarian notation?
- krallja 11y ago
  Wasabi is statically typed — `dynamic` wasn't added to C# until C# 4, in 2010, so the implementation choice was between static types and a LOT of reflection. The type inferencer was an attempt to make it as easy to declare variables and functions as it was in VBScript. Of course, you could explicitly declare types as well. The one place Wasabi depends on Hungarian notation as a type heuristic is when reading from an ADO RecordSet (which happens quite frequently in FogBugz). The column name determines which type the returned object will be cast into.
  - mwcampbell 11y ago
    How much of the FogBugz code had to be modified to accommodate static typing, even with global type inference? In other words, was there much code that truly depended on dynamic typing? My guess is that Joel and his team were more disciplined about this than I've been. (Yes, I'm entertaining the idea of writing a custom compiler from a dynamically typed language, in my case Lua, to a statically typed one, probably C++ with heavy use of reference counting.)
    - krallja 11y ago
      Very little, if I remember correctly. The FogBugz coding conventions meticulously follow Apps Hungarian (http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html), which means that the type of a variable should not change.
Locke1689 11y ago
Super excited to see what you did with Roslyn! We'd love feedback on things we could do to improve the experience!
- krallja 11y ago
  Thanks Andy! Really short feedback: - SyntaxTrivia is a great idea, if a little hard to grok. I wish I'd have thought of it for Wasabi's comments. (CComment inherits from CStatement, which is CLEARLY wrong.) - The SyntaxKind enum is a giant blob of magic numbers. I would have appreciated it being implemented as sum types.
  - Locke1689 11y ago
    Thanks krallja! I hear you about the enum -- it's not the best programming experience. Unfortunately, for performance it's much faster for SyntaxTokens to be struct types, which means no inheritance and thus no sum types. In addition, the SyntaxKind allows a faster check on the SyntaxToken Kind since you can simply pull an int field, rather than having to do a runtime type check.
tptacek 11y ago
I'd really, really like to read _Wasabi – The ??? parts_.
- krallja 11y ago
  I'll see if I can make that happen.
  - tptacek 11y ago
    Thank you! I can't be the only one here psyched to read a case study like this.
- krallja 11y ago
  Wasabi: The ??? Parts http://jacob.jkrall.net/wasabi-the-parts/ http://jacob.jkrall.net/wasabi-the-parts/
  - tptacek 11y ago
    I'm like 2 paragraphs in and already publishing this is a total win: Thistle was origionally an intern project to produce a source-to-source translator that translated ASP into PHP by adding dollar signs to variable names and implementing LBound and UBound in PHP Thank you so much for ruining my productivity for a couple hours. :)
chkuendig 11y ago
Related from Jeff Atwood: http://blog.codinghorror.com/has-joel-spolsky-jumped-the-shark/ http://blog.codinghorror.com/has-joel-spolsky-jumped-the-sha... It's funny how they teamed up 2 years later to build stack overflow (and again used an MS stack)
adnam 11y ago
Worth recalling what DHH had to say about Wasabi in 2006: http://david.heinemeierhansson.com/arc/2006_09.html http://david.heinemeierhansson.com/arc/2006_09.html Scroll down to the part "Fear, Uncertain, and Doubt by Joel Spolsky" from September 01 (permalink 404s)
- emodendroket 11y ago
  Well, gee, I don't know if I have anything else to add to this discussion after reading that.
  - slantyyz 11y ago
    Well, 2006 was a -long- time ago, and Ruby and Ruby on Rails have come a long way. I don't think Joel's conservative approach was all that bad. He made a judgment call for --his-- company's products at the time. He could afford to, and it appeared to have worked well for his product line. And believe it or not, people wanted to work at Fog Creek. In 2006, I wouldn't have imagined the explosion of language acceptability that we have today. We see everything from Ruby, Erlang, Scala and other languages widely used -- a great thing that you can use the best language for software development instead of being limited to the "safe enterprise" choices of Java or Microsoft .NET.
    - emodendroket 11y ago
      But, as the linked post points out, all those arguments fall by the wayside when the alternative is an in-house language used by no other production project on Earth. Developing your own language is not really "conservative" at all.
      - slantyyz 11y ago
        But the in-house language was basically a variant of Visual Basic. They basically created their own DSL because they didn't feel like any other tool satisfied their needs. Joel's not an idiot -- I'm sure he weighed the cost of doing his own language vs. the alternatives and found that the direction he took was the better way for the time. It would have been more of a mistake if Fogbugz turned out to be a load of crap, but it's pretty good. I prefer it to JIRA.
robotnoises 11y ago
This is off-topic, but how is it that this is the top story on HN right now with zero discussion (assuming that by the time I click "add comment" I am the first to comment). Is it dumb to assume that it's normal for upvotes and comments to increase at a similar rate?
- codegeek 11y ago
  Writing a good comment takes effort. Interesting posts are upvoted just so that they can be part of a discussion even if you are not the one starting the discussion. I do this all the time. If I feel that I can add to the discussion, I will write up a comment later.
  - robotnoises 11y ago
    That makes sense. I guess I just assumed that the pattern would be more like this: 1.) See headline 2.) If the user enjoyed the read, they click upvote 3.) (Maybe) comment What you are suggesting is that it's more like this: 1.) See headline 2.) Click upvote 3.) Read link 4.) (Maybe) comment
    - scott_s 11y ago
      Not necessarily. codegeek's point holds for both patterns; it's a statement on upvoting a submission for potential discussion.
    - ad_hominem 11y ago
      I think you misinterpreted what codegeek wrote. People won't comment if they feel they don't have anything of substance to add - sometimes submissions can stand on their own pretty well and thus don't solicit a lot of comments. It's about maintaining a high signal-to-noise ratio. If anything I've found that you can use the karma/comment ratio as a moderately reliable indicator of link quality. As for your original question, you should probably "lurk moar" before starting off-topic discussions. This really isn't that uncommon.
- striking 11y ago
zak_mc_kracken 11y ago
It's always struck me as extremely bizarre that a company that regularly advertises that it's at the bleeding edge of software engineering practices (see Spolsky's numerous blog posts on the topic) made such a colossal error as writing their own language, and that it took them a decade to realize this mistake. I also find this kind of phrasing weird: > 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. It's like the author of this article goes out of their ways to avoid saying that some people left the company, period. It also wouldn't surprise me if some of these defections were caused by Wasabi itself. As a software engineer, you quickly start wondering how wise it is to spend years learning a language that will be of no use once you leave your current company (yet another reason why rolling your own language as a critical part of your product is a terrible idea).
- joshstrange 11y ago
  > It's like the author of this article goes out of their ways to avoid saying that some people left the company, period. It also wouldn't surprise me if some of these defections were caused by Wasabi itself. As a software engineer, you quickly start wondering how wise it is to spend years learning a language that will be of no use once you leave your current company (yet another reason why rolling your own language as a critical part of your product is a terrible idea). I also found that passage oddly worded. We get it, people don't stick around forever, you don't have to try and hide it like it's some dirty little secret. Also as developer I doubt I would have wanted anything to do with a closed-source internal-only poorly-documented language. You may learn some concepts that transfer but by and large you will have to start from scratch when you leave and you won't have skills people are looking for. Also if you do dive headfirst into Wasabi and love it and then leave you probably will be that annoying fuck at your new company that says shit like "Well in Wasabi this was easy...." or "Wasabi makes this problem non-existant because...." Shut up, no one cares. It's crazy to me to think of a company as small as Fog Creek would attempt something like this but to be fair I was born and learned to develop in a different environment than they did so maybe the tools and languages available back then really just couldn't cut it.
- ExpiredLink 11y ago
noir_lord 11y ago
They tried something interesting, it didn't work and they replaced it later. When this has been mentioned previously there is a strong "they did a crazy thing with Wasabi" but progress depends on doing crazy things that just might work sometimes.
- jfb 11y ago
  They got almost 10 years out of it. Even with accumulating technical debt, that reads like a success to me.
Marazan 11y ago
The killer lines from the blog post is that they are killing off Wasabi for exactly the reasons that everyone said would make it a bad idea 1) Maintenance Nightmare 2) No-one likes programming in propriety language as it dead ends your career 3) Company leavers take vast amounts of knowledge away with them and impossible to hire-in to replace that knowledge
- joshdick 11y ago
  Those predictions were still off by ten years, however. Wasabi served them well until other technologies improved enough to allow them to ditch Wasabi.
- scotch_drinker 11y ago
  The fact that they are killing it off after 10 years of very profitable use tells me the line between good and bad idea is very gray.
  - Marazan 11y ago
    We have no idea how much friction they've experienced over the years due to the decision to roll their own language. Just because they've been successful doesn't mean they haven't expended unnecessary effort to get there. Climbing a mountain carrying an extra unnecessary 15 kilos is still successfully climbing a mountain - but carrying an extra 15 kilos whilst doing so is still a bad idea.
    - thedufer 11y ago
      You have to think _very_ highly of Fog Creek to believe that they've been so successful despite making a massive strategic blunder a few years in.
      - Marazan 11y ago
        Companies succeed all the time despite making terrible decisions or sub-optimal choices. Speak to anyone at almost any company and you will get at least one story of some unbelievably bone headed strategic mistake the company is making.
tempodox 11y ago
Building an in-house compiler rarely makes sense. Dang, it's significantly less entertaining but I'm afraid he's right.
- deleted 11y ago
  [deleted]
userbinator 11y ago
This seems like the logical conclusion of the inner-platform effect: https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect
protomyth 11y ago
I do wonder what the difference would have been had it been open sourced early on? I would think a tool that had a VBScript-like syntax that could deploy to PHP would have been a popular item with enterprise developers for the same reason it appealed to Fog Creek.
- kej 11y ago
  I seem to recall some comments at the time that it wasn't worth opening or selling because it was tailored specifically to their code. For example, it relied on their naming conventions to determine whether a string was safe to display or not, so non-Fog Creek code wouldn't really work with it.
michaelbuckbee 11y ago
It's not mentioned in the article, but I suspect another factor was the growth of their SAAS (aka "Fogbugz on Demand") offering - which obviously severely undercuts the value of Wasabi. It's listed from a Google search, but from just clicking around the Fogbugz site I can't even find the page/pricing for on premise installation.
stevoski 11y ago
Why I'd never develop a Wasabi in my company: When I learn a new, perhaps hyped-up computer language, I soon run into difficulties, no matter what the merits of the language. The difficulties are lack of tooling. eg, no debugger - or only a rudimentary one, no static analysis, no refactoring, no advanced code browser. If the language is successful, these things come with time. When you develop an in-house language, you'll never get the advanced tooling that makes for a great software development experience. This, for me, was why I was surprised by Joel Spolsky's announcement of an in-house language. (Although, to be fair, these things didn't really exist of VBScript nor for PHP at the time Wasabi came to be.)
- slantyyz 11y ago
  Don't people create things like Wasabi all the time? Aren't tools like RubyMotion, Appcelerator and their ilk kinda similar to Wasabi in terms of what they do? You might even make the argument that Coffeescript is somewhat similar to Wasabi.
- wvenable 11y ago
  I think your bracketed comment says it all; there was no obvious alternative at that time which would satisfy the market conditions. The VBScript version was super easy to install for most companies with the servers they already had available. They had a selling feature which was entirely dependent on this terrible technology. So they mitigated it. It's all pretty reasonable.
cjensen 11y ago
Replacing Wasabi code with the prettified output of Wasabi seems like a terrible idea to me. Is the result similar enough to the original source that it will still make sense? Do comments get preserved? Programmers just love to change good working code into the new style or new language. One has to always view the impulse to change skeptically.
- krallja 11y ago
  I'll make sure to include some example output in my next article. It's pretty readable - not quite idiomatic C#, but you can almost always see what's going on. It's very conservative C#, and it still uses the same style of coding that the original source used - ADO and `Response.Write`, rather than WebForms or ASP.NET MVC. This project had the full support of the company, from our newest hires all the way to Joel and Michael. As many people have noted, using this wacky one-off language was a source of a lot of friction in our business, and we felt that spending a few months to get rid of that friction would be a good use of resources (me).
brlewis 11y ago
We hadn’t open-sourced it, so this meant any investment had to be done by us at the expense of our main revenue-generating products. While we were busy working on exciting new things, Wasabi stagnated. It was a huge dependency that required a full-time developer — not cheap for a company of our size. The way I read this article, creating Wasabi a decade ago was not a mistake, given what they were doing and what was available at the time. Not open-sourcing Wasabi was a mistake, though.
- gecko 11y ago
  I agree. Especially when we first had Wasabi, there were a lot of other legacy ASP code bases lying around, and I think we could've both helped ourselves and gotten more community support by going that route. But it's also worth remembering this was before GitHub; this would've meant a SourceForge account, mailing lists, etc.—a reasonable extra use of resources. It wasn't as trivial a decision then.
Udo 11y ago
> Building an in-house compiler rarely makes sense. I disagree. First of all, Wasabi solved a real problem which doesn't exist anymore: customers had limited platform support available and Fog Creek needed to increase the surface area of their product to cover as many of the disparate platforms as possible. Today, if all else fails, people can just fire up an arbitrarily configured VM or container. There is much less pressure to, for example, make something that runs on both ASP.NET and PHP. We are now in the fortunate position to pick just one and go for it. Second, experimenting with language design should not be reserved for theoreticians and gurus. It should be a viable option for normal CS people in normal companies. And for what it's worth, Wasabi might have become a noteworthy language outside Fog Creek. There was no way to know at the time. In hindsight, it didn't, but very few people have the luxury of designing a language which they know upfront will be huge. For example, Erlang started out being an internal tool at just one company, designed to solve a specific set of problems. Had they decided that doing their own platform was doomed to fail, the world would be poorer for it today.
- marktangotango 11y ago
  >> Second, experimenting with language design should not be reserved for theoreticians and gurus. It should be a viable option for normal CS people in normal companies. One might think so, if one is charitable toward the typical developer and they're abilities. I worked at a place that had implemented their own query language and integrated it into their core product. The query language was interpreted, and walked structured text files stored on disk. Worked great for small installations, but as the company grew, acquiring larger clients, clients data corpi grew, performance fell of a cliff. The syntax of the language was all over the board, users would cut and paste to combine little recipes to do things, there was a never ending stream of support calls as to why this didn't work like this, and why couldn't this do this like this other part does that. Edit; wanted to say consistent, logical syntax is were someone with experience in language theory and implementation would have made an impact. The language as was, was the result of feature accretion. I think someone with knowledge would have attempted to craft a kernel of functionality, and back it with a more robust datastore (sql). Edit2: also want to clarify, the developers who did the implementation were actually quite talented, the project was simply not something they were equipped to deal with, and really weren't given the oppurtunity to refine or iterate on. Edit3: I offer this as an example of one company that implemented they're own langauge, of course the purpose of this example differs from wasabi, and is not intended to condemn or denigrate Wasabi, or Fogcreek. I guess it was a net win, but it was painful.
scotch_drinker 11y ago
Wasabi was technical debt. Like all forms of debt, there is productive and unproductive technical debt. Productive technical debt actually give some return on that debt. Unproductive technical debt doesn't. Given the fact that Wasabi lasted 10 years (and the company seems to have made a bunch of money because of it) and because Wasabi gave them the ability to adjust to market factors, I'd say the payoff from this technical debt was highly justified. All technical debt decisions should be made based on what the business hopes to get from the debt. Considerations for the alternatives, when the debt is retired, etc should all play a part. To globally say "this is a terrible idea" like so many in this thread are doing totally ignores these types of factors in favor of "It's a bad computer science" idea and thus miss the point of technical debt in the first place.
- jfb 11y ago
  It's not even remotely a bad CS idea, however. It's taking long established praxis with a sound theoretical background and applying it to a problem that that practice was intended to solve.
tptacek 11y ago
The author has graciously posted _Wasabi, The ??? Parts_, the internal book about Wasabi mentioned in the blog, on their website: http://jacob.jkrall.net/wasabi-the-parts/index.html http://jacob.jkrall.net/wasabi-the-parts/index.html Having now read it, I've come to the conclusion that the blog gives the wrong impression about the implications of having a custom language. Readers of the blog post come away with the idea that Wasabi was so full of "o.O" that someone was moved to write a book about that. In reality, the book is simply documentation of the language features, with callouts for weird interactions between VB-isms, ASP.NET-isms, and their language. You should definitely read the "Brief And Highly Inaccurate History Of Wasabi" that leads the document off. It's actually very easy now to see how they ended up with Wasabi: 1. The ASP->PHP conversion was extremely low-hanging fruit (the conversion involved almost no logic). 2. Postprocessing ASP meant PHP always lagged, so they started generating ASP from the same processor. 3. Now that all their FogBugz code hits the preprocessor, it makes sense to add convenience functions to it. 4. Microsoft deprecates ASP. FogBugz needs to target ASP.NET. They can manually port, or upgrade the preprocessor to do that for them. They choose the latter option: now they have their own language. It's step (3) where they irrevocably commit themselves to a new language. They want things like type inference and nicer loops and some of the kinds of things every Lisp programmer automatically reaches for macros to get. They have this preprocessor. So it's easy to add those things. Now they're not an ASP application anymore. Quick rant: if this had been a Lisp project, and they'd accomplished this stuff by writing macros, we'd be talking this up as a case study for why Lisp is awesome. But instead because they started from unequivocally terrible languages and added the features with parsers and syntax trees and codegen, the whole project is heresy. Respectfully, I call bullshit.
- TheMakeA 11y ago
  I agree. It also seems like they had a relatively straight forward migration path that worked out really well. Sounds like good decisions were made at the right times.
- tedunangst 11y ago
  Another perspective, if you're into wasabi history: http://www.tedunangst.com/flak/post/technical-debt-and-tacking-into-the-wind http://www.tedunangst.com/flak/post/technical-debt-and-tacki...
_pmf_ 11y ago
It's strange that the HN crowd, consisting mostly of developers who work for companies that exist on average for 16 months, has the audacity of calling Wasabi, a tool that has been in use for close to 15 years, a failure.
- yellowapple 11y ago
  Probably because it isn't some hipster badass ninja rockstar web-scale pipe-to-dev-null Wangular.js Ruby-on-Fails Web-2.0 SaaS app, and therefore automatically a failure.
  - serve_yay 11y ago
    I disagree, it is exactly that. Badass ninja rockstars are exactly the people who decide to make this sort of thing. (Then they leave for the next thing, like they always do, and their coworkers are left with a pile of "??????????????")
    - mwcampbell 11y ago
      What would you have done, given the starting point of a VBScript codebase, to bring it to Unix and later to .NET? Remember, it does no good to talk about what should have been, years before. You have to make the best decision with what you already have. In that light, writing a custom compiler for a variant of VBScript doesn't seem so bad.
      - serve_yay 11y ago
        If your point is that it was strategically necessary given the constraints at the time, that's fine with me. There are lots of terrible things that became strategically necessary due to the past decisions of business people. I still wouldn't want to have to learn this language, would you?
        spc476 11y ago
        I would. I might not like it, but I can't say for sure now, not having used it. And you never know, there could be some good ideas lurking deep inside. I recently played around with Atari 2600 BASIC (which is quite possibly worse emulated than on a real system) but found that it had an incredible tracing mechanism I've never seen elsewhere. Also, you could control the speed of execution as the programs runs (imagine---running a program at full speed, then slowing down to watch exactly what happens). You won't know until you try. (http://boston.conman.org/2015/06/16.1 http://boston.conman.org/2015/06/16.1)
pablosanta 11y ago
Has Joel jumped the shark? http://blog.codinghorror.com/has-joel-spolsky-jumped-the-shark/ http://blog.codinghorror.com/has-joel-spolsky-jumped-the-sha... Related blog post from a couple of years ago.
- lubos 11y ago
  This is the first thing that came to my mind too.
serve_yay 11y ago
I guess this worked for them, for some value of the word "worked", but it always seemed like a bad idea to me.
narrator 11y ago
You could have just started on Java. I've worked on very large 15 year old Java enterprise code bases that are doing just fine. That language is so pathetically maintainable and the backward compatibility between JVM releases is very good. Microsoft seems like a moving target with how often they deprecate things.
davelnewton 11y ago
Isn't this exactly what everybody said when they announced Wasabi in the first place?
mixmastamyk 11y ago
Wow, rabbit hole is right... The first mistake was writing a web-app in VBScript (not VB) ?? I'm not even sure that's possible, it's such an awful, limited language. Probably required components written in C++? The developer who started that should have been fired as incompetent. These are the "B-players in a hurry" you should get rid of, that can cost your company millions. Then instead of cutting their losses, they doubled and tripled-down on it until they had their own language and sophisticated tools around it. Around this time, Django and Rails had been started already. And several decent cross-platform web frameworks were years old, such as CherryPy. Even PHP would have been a better choice. One of these could have been phased-in parts at a time to minimize disruption. Did I get this right? Because there are so many WTFs that I must have missed something.
- willu 11y ago
  VBScript is the language of Classic ASP. Many, many sites were written with that technology ~15 years ago and some are still around. An unpleasant language, yes, but certainly not an incompetent decision at the time.
- wvenable 11y ago
  VBScript was literally the prescribed way of building web applications for IIS. This was a long time ago and things were way different than they were now. ASP was a revelation compared how web applications were built prior to it's introduction. It seems archaic now but those were archaic times.
  - mixmastamyk 11y ago
    I seem to remember numerous frameworks being around for quite a while at that point. They could have used Thistle to move to PHP ten years ago and saved a lot of money.
- tghw 11y ago
  First, Classic ASP was equivalent to PHP in many ways. VBScript was the functional part of ASP. Go read more before you criticize: https://en.wikipedia.org/wiki/Active_Server_Pages https://en.wikipedia.org/wiki/Active_Server_Pages Second, the "developer who started that" were the founders. One had worked at Microsoft, and so was very familiar with ASP. Third, FogBugz was a complex, mature application by the time Django or Rails were even considerations for production systems. Phasing in in parts is not really a viable solution either. There was a lot of business logic written and shared that those new parts would need access to, which would create more work to implement. In short, no, you did not. You're looking at decisions made 10 years ago through today's lens, without considering the state of the art at the time. (In case you're wondering, I worked at Fog Creek from 2005-2012, though I was never a part of the FogBugz team.)
10098 11y ago
I wonder how much time and money they would save if they had just bitten the bullet and rewritten the entire thing in PHP in the first place instead of doing what they did.
- wvenable 11y ago
  The big advantage of the ASP/VBScript version is that there were almost no dependencies and it would install on the most basic IIS setup. Many companies already had IIS installed and configured but not doing anything. Getting companies to install PHP on Windows (a dicey position those days) was a non-starter.
Lazare 11y ago
It's fascinating, because writing your own custom language is one of those things that everyone knows is a bad idea. It's one of those things that people do because it seems like the path of least resistance (and in the short run, is), but it inevitably snowballs into a pit of technical debt. Spolsky knew this quite well (he'd written eloquently on the subject). ...and yet he still did it. His defence was that it was the easiest option in the short term, and he was probably right, but it doesn't matter. People only do stupid stuff that seems smart; saying "this stupid thing seems smart!" is only a defence if you have no idea that it's actually fundamentally stupid. Of all the people in the world, Spolsky is one of the least able to mount this defence. Contemporaneously with his decision to go all in on Wasabi, he wrote a scathing condemnation of Ruby for being slow, unserious, obscure; he suggested that a serious company shouldn't opt for Ruby because it was risky, and that choosing it would put you at risk of getting fired. Was he right? In 2006, maybe? I mean, he turned out to be wrong, but I don't think it was entirely obvious that Ruby was a serious choice 15 years ago. Of course, he wasn't writing 15 years ago, but even nine years ago, a very conservative, safe approach to choosing a technical stack very possibly did mitigate against selecting Ruby, for all the reasons he outlined. But those arguments applied twice as hard to Wasabi. You don't get to argue that there "just isn't a lot of experience in the world building big mission critical web systems in Ruby" (and hence you shouldn't use Ruby), and then turn around and use Wasabi for your big mission critical web system. Of all the people in the world, Spolsky probably had the best understanding of why Wasabi was a stupid, short sighted decision. He did it anyway. And it was stupid and short sighted. Rarely is someone so right and so wrong about the same thing at once. (And yes, Fogcreek is still around, and so is FogBugz. But I don't buy for a moment that Wasabi was actually a good choice. They survived it, but they didn't benefit from it.) Edit: Spolsky has written too much about why things like writing something like Wasabi is terrible idea to link it all. Besides, a lot of it has been linked in other comments. But I don't think I can express strongly enough that my anti-Wasabi position is simply repeating the things the guy that signed off on developing it and using in production wrote. ...then he decided to write a new language because apparently Ruby was too slow to possibly use to generate a graph, and there was literally no alternative to using Ruby for graph generating than writing your own compile-to-VBScript/PHP language. Words fail.
bootload 11y ago
"the fact remains that we had a Classic ASP application running on Linux and we didn’t have to pay anybody for the privilege." [0] Commercial reasons dictated why Wasabi was created and retired. Bravo Joel. [0] http://jacob.jkrall.net/wasabi-the-parts/introduction.html http://jacob.jkrall.net/wasabi-the-parts/introduction.html
overgard 11y ago
One thing I've always wondered (and I don't intend this as a criticism per se), but why didn't they open source it? If it had a following outside of Fog Creek it might not have been an inevitable dead end. While I hesitate to endorse a language based on VBScript, it seems like the extensions they added to it were pretty nice. I mean, if you're inclined to use a VBScript style language, Wasabi wasn't horrible, and given Spolsky's following and Fog Creek's mindshare, it seems at least possible it could have become a useful thing rather than a legacy thing to be replaced. I mean, at the very least, it's probably not worse than PHP. (Granted: my opinion of PHP is very low). Maybe it's for the best though, the world is probably better off without new wasabi projects.
- krallja 11y ago
  Looking back, I regret not open sourcing it as well. Pre-.NET, we didn't want to spoil our cross-platform competitive advantage. Post-.NET, we didn't think there was much of a market for a VBScript-to-C# transpiler (wouldn't those people prefer VB.NET?), and besides, open sourcing it seemed like a lot of work for basically no benefit.
  - overgard 11y ago
    I get that, running an open source project can be very time consuming and expensive, and once it starts it becomes a part of your brand that cannot necessarily easily be dismissed. So it may have been wise not to open source it. I do think though, that wasabi was not obviously stupid or anything, and it probably could have had some amount of success in the wild.

Killing Off Wasabi

309 points by GarethX 11y ago

jim_greco 11y ago

A company should never build a compiler, database, or operating system if it is not their primary business.

wiredfool 11y ago
Or source control.
- ohitsdom 11y ago
  Or chat tool, or bug tracker, or... The list goes on. Basically, focus on your core business. If you spend more than ~10% of your time building infrastructure tools, someone else probably does it better, for cheaper.
ygra 11y ago
As someone working on a compiler which is not a primary business of this company I disagree. Our main product is a large library with quite a lot man-years of work put into it that we offer on lots of different platforms and frameworks – for the most part with near-identical API and capabilities. Compiling the source into different languages rather than rewriting everything is a very valid approach. In our case almost all bugfixes and new features can be merged directly into the other products and work (the exception being the glue parts to the respective platform/framework). Being able to precisely control the output and thus guarantee API stability is a major factor in developing this in-house, especially as most converters only concern themselves with replicating the visible behaviour of a complete application.
- beambot 11y ago
  If you license the library, why not directly cross-compile it (using existing compilers) and then just write wrappers to expose it in the target languages?
kyllo 11y ago
I think it's perfectly legitimate for a company to build those things when it's not their core business, provided that A. They hire people who are legitimate experts and give them free reign to work on it, and B. They open-source it. A lot of quality compilers and databases have come from software companies whose primary business is neither a compiler nor a database.
codemac 11y ago
I disagree, because there are SO many examples of companies and products that do this. Basically every data storage company, every networking company, every database company (meaning they wrote the OS).. Not to mention wasabi is a transpiler! It took VB-ish stuff and turned it into a few target languages. This is senior year undergrad complexity that they used for 10 years. The negativity on this post is astounding.
- krallja 11y ago
  Writing a compiler sounds scary to some people. It's not scary. The only compilers training I have is a senior-year undergraduate course, and quite a lot of that was learning all the different ways to write parsers. Wasabi uses a LL(k) recursive descent parser, and you don't have to know what that means to be able to work on it. I've never even read the Dragon book; we used Cooper & Torczon "Engineering a Compiler" instead.
braythwayt 11y ago
I think you're close. A company should never do secondary business X if their proprietary take on X does not contribute to their value proposition in a way that external solutions cannot provide. At one time, for example, ice companies did their own deliveries because they needed special hore-drawn carriages to keep the ice cold.
jfb 11y ago
This is silly. If you make a reasoned decision, taking into account your specific circumstances and the projected changes to come over the midterm, and you decide to do this, well, why not? Should Google not have built go? Should Jane Street not have built core? Should Facebook not have built their suite of tools? I'm comfortable saying that the super smart people who advocated for those projects (among numerous others) had a pretty good case to make.
- jim_greco 11y ago
  Why not? Because it creates a maintenance nightmare and if it's not your core business that means it will never be a priority. Using Google and Facebook as a counter-example is silly. These are $250B+ companies and these tools are a significant part of their business.

mwcampbell 11y ago

A lot of people criticize Fog Creek for writing their own compiler, but I think it's a good example of working smarter rather than harder to solve a problem they had at the time. I think that companies which apply sheer brute force to rewrite the same app in Objective-C and Java to target the popular mobile platforms could learn from this. I wonder to what extent the generated C# code depends on C#'s dynamic typing option. I ask because the original VBScript was certainly dynamically typed. So by the end, to what extent was Wasabi statically typed, through explicit type declarations or type inference? And how much did the compiler have to rely on naming conventions such as Hungarian notation?

krallja 11y ago
Wasabi is statically typed — `dynamic` wasn't added to C# until C# 4, in 2010, so the implementation choice was between static types and a LOT of reflection. The type inferencer was an attempt to make it as easy to declare variables and functions as it was in VBScript. Of course, you could explicitly declare types as well. The one place Wasabi depends on Hungarian notation as a type heuristic is when reading from an ADO RecordSet (which happens quite frequently in FogBugz). The column name determines which type the returned object will be cast into.
- mwcampbell 11y ago
  How much of the FogBugz code had to be modified to accommodate static typing, even with global type inference? In other words, was there much code that truly depended on dynamic typing? My guess is that Joel and his team were more disciplined about this than I've been. (Yes, I'm entertaining the idea of writing a custom compiler from a dynamically typed language, in my case Lua, to a statically typed one, probably C++ with heavy use of reference counting.)
  - krallja 11y ago
    Very little, if I remember correctly. The FogBugz coding conventions meticulously follow Apps Hungarian (http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html), which means that the type of a variable should not change.

Locke1689 11y ago

Super excited to see what you did with Roslyn! We'd love feedback on things we could do to improve the experience!

krallja 11y ago
Thanks Andy! Really short feedback: - SyntaxTrivia is a great idea, if a little hard to grok. I wish I'd have thought of it for Wasabi's comments. (CComment inherits from CStatement, which is CLEARLY wrong.) - The SyntaxKind enum is a giant blob of magic numbers. I would have appreciated it being implemented as sum types.
- Locke1689 11y ago
  Thanks krallja! I hear you about the enum -- it's not the best programming experience. Unfortunately, for performance it's much faster for SyntaxTokens to be struct types, which means no inheritance and thus no sum types. In addition, the SyntaxKind allows a faster check on the SyntaxToken Kind since you can simply pull an int field, rather than having to do a runtime type check.

tptacek 11y ago

I'd really, really like to read _Wasabi – The ??? parts_.

krallja 11y ago
I'll see if I can make that happen.
- tptacek 11y ago
  Thank you! I can't be the only one here psyched to read a case study like this.
krallja 11y ago
Wasabi: The ??? Parts http://jacob.jkrall.net/wasabi-the-parts/ http://jacob.jkrall.net/wasabi-the-parts/
- tptacek 11y ago
  I'm like 2 paragraphs in and already publishing this is a total win: Thistle was origionally an intern project to produce a source-to-source translator that translated ASP into PHP by adding dollar signs to variable names and implementing LBound and UBound in PHP Thank you so much for ruining my productivity for a couple hours. :)

chkuendig 11y ago

Related from Jeff Atwood: http://blog.codinghorror.com/has-joel-spolsky-jumped-the-shark/ http://blog.codinghorror.com/has-joel-spolsky-jumped-the-sha... It's funny how they teamed up 2 years later to build stack overflow (and again used an MS stack)

adnam 11y ago

Worth recalling what DHH had to say about Wasabi in 2006: http://david.heinemeierhansson.com/arc/2006_09.html http://david.heinemeierhansson.com/arc/2006_09.html Scroll down to the part "Fear, Uncertain, and Doubt by Joel Spolsky" from September 01 (permalink 404s)

emodendroket 11y ago
Well, gee, I don't know if I have anything else to add to this discussion after reading that.
- slantyyz 11y ago
  Well, 2006 was a -long- time ago, and Ruby and Ruby on Rails have come a long way. I don't think Joel's conservative approach was all that bad. He made a judgment call for --his-- company's products at the time. He could afford to, and it appeared to have worked well for his product line. And believe it or not, people wanted to work at Fog Creek. In 2006, I wouldn't have imagined the explosion of language acceptability that we have today. We see everything from Ruby, Erlang, Scala and other languages widely used -- a great thing that you can use the best language for software development instead of being limited to the "safe enterprise" choices of Java or Microsoft .NET.
  - emodendroket 11y ago
    But, as the linked post points out, all those arguments fall by the wayside when the alternative is an in-house language used by no other production project on Earth. Developing your own language is not really "conservative" at all.
    - slantyyz 11y ago
      But the in-house language was basically a variant of Visual Basic. They basically created their own DSL because they didn't feel like any other tool satisfied their needs. Joel's not an idiot -- I'm sure he weighed the cost of doing his own language vs. the alternatives and found that the direction he took was the better way for the time. It would have been more of a mistake if Fogbugz turned out to be a load of crap, but it's pretty good. I prefer it to JIRA.

robotnoises 11y ago

This is off-topic, but how is it that this is the top story on HN right now with zero discussion (assuming that by the time I click "add comment" I am the first to comment). Is it dumb to assume that it's normal for upvotes and comments to increase at a similar rate?

codegeek 11y ago
Writing a good comment takes effort. Interesting posts are upvoted just so that they can be part of a discussion even if you are not the one starting the discussion. I do this all the time. If I feel that I can add to the discussion, I will write up a comment later.
- robotnoises 11y ago
  That makes sense. I guess I just assumed that the pattern would be more like this: 1.) See headline 2.) If the user enjoyed the read, they click upvote 3.) (Maybe) comment What you are suggesting is that it's more like this: 1.) See headline 2.) Click upvote 3.) Read link 4.) (Maybe) comment
  - scott_s 11y ago
    Not necessarily. codegeek's point holds for both patterns; it's a statement on upvoting a submission for potential discussion.
  - ad_hominem 11y ago
    I think you misinterpreted what codegeek wrote. People won't comment if they feel they don't have anything of substance to add - sometimes submissions can stand on their own pretty well and thus don't solicit a lot of comments. It's about maintaining a high signal-to-noise ratio. If anything I've found that you can use the karma/comment ratio as a moderately reliable indicator of link quality. As for your original question, you should probably "lurk moar" before starting off-topic discussions. This really isn't that uncommon.
striking 11y ago

zak_mc_kracken 11y ago

It's always struck me as extremely bizarre that a company that regularly advertises that it's at the bleeding edge of software engineering practices (see Spolsky's numerous blog posts on the topic) made such a colossal error as writing their own language, and that it took them a decade to realize this mistake. I also find this kind of phrasing weird: > 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. It's like the author of this article goes out of their ways to avoid saying that some people left the company, period. It also wouldn't surprise me if some of these defections were caused by Wasabi itself. As a software engineer, you quickly start wondering how wise it is to spend years learning a language that will be of no use once you leave your current company (yet another reason why rolling your own language as a critical part of your product is a terrible idea).

joshstrange 11y ago
> It's like the author of this article goes out of their ways to avoid saying that some people left the company, period. It also wouldn't surprise me if some of these defections were caused by Wasabi itself. As a software engineer, you quickly start wondering how wise it is to spend years learning a language that will be of no use once you leave your current company (yet another reason why rolling your own language as a critical part of your product is a terrible idea). I also found that passage oddly worded. We get it, people don't stick around forever, you don't have to try and hide it like it's some dirty little secret. Also as developer I doubt I would have wanted anything to do with a closed-source internal-only poorly-documented language. You may learn some concepts that transfer but by and large you will have to start from scratch when you leave and you won't have skills people are looking for. Also if you do dive headfirst into Wasabi and love it and then leave you probably will be that annoying fuck at your new company that says shit like "Well in Wasabi this was easy...." or "Wasabi makes this problem non-existant because...." Shut up, no one cares. It's crazy to me to think of a company as small as Fog Creek would attempt something like this but to be fair I was born and learned to develop in a different environment than they did so maybe the tools and languages available back then really just couldn't cut it.
ExpiredLink 11y ago

noir_lord 11y ago

They tried something interesting, it didn't work and they replaced it later. When this has been mentioned previously there is a strong "they did a crazy thing with Wasabi" but progress depends on doing crazy things that just might work sometimes.

jfb 11y ago
They got almost 10 years out of it. Even with accumulating technical debt, that reads like a success to me.

Marazan 11y ago

The killer lines from the blog post is that they are killing off Wasabi for exactly the reasons that everyone said would make it a bad idea 1) Maintenance Nightmare 2) No-one likes programming in propriety language as it dead ends your career 3) Company leavers take vast amounts of knowledge away with them and impossible to hire-in to replace that knowledge

joshdick 11y ago
Those predictions were still off by ten years, however. Wasabi served them well until other technologies improved enough to allow them to ditch Wasabi.
scotch_drinker 11y ago
The fact that they are killing it off after 10 years of very profitable use tells me the line between good and bad idea is very gray.
- Marazan 11y ago
  We have no idea how much friction they've experienced over the years due to the decision to roll their own language. Just because they've been successful doesn't mean they haven't expended unnecessary effort to get there. Climbing a mountain carrying an extra unnecessary 15 kilos is still successfully climbing a mountain - but carrying an extra 15 kilos whilst doing so is still a bad idea.
  - thedufer 11y ago
    You have to think _very_ highly of Fog Creek to believe that they've been so successful despite making a massive strategic blunder a few years in.
    - Marazan 11y ago
      Companies succeed all the time despite making terrible decisions or sub-optimal choices. Speak to anyone at almost any company and you will get at least one story of some unbelievably bone headed strategic mistake the company is making.

tempodox 11y ago

Building an in-house compiler rarely makes sense. Dang, it's significantly less entertaining but I'm afraid he's right.

deleted 11y ago
[deleted]

userbinator 11y ago

This seems like the logical conclusion of the inner-platform effect: https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect

protomyth 11y ago

I do wonder what the difference would have been had it been open sourced early on? I would think a tool that had a VBScript-like syntax that could deploy to PHP would have been a popular item with enterprise developers for the same reason it appealed to Fog Creek.

kej 11y ago
I seem to recall some comments at the time that it wasn't worth opening or selling because it was tailored specifically to their code. For example, it relied on their naming conventions to determine whether a string was safe to display or not, so non-Fog Creek code wouldn't really work with it.

michaelbuckbee 11y ago

It's not mentioned in the article, but I suspect another factor was the growth of their SAAS (aka "Fogbugz on Demand") offering - which obviously severely undercuts the value of Wasabi. It's listed from a Google search, but from just clicking around the Fogbugz site I can't even find the page/pricing for on premise installation.

stevoski 11y ago

Why I'd never develop a Wasabi in my company: When I learn a new, perhaps hyped-up computer language, I soon run into difficulties, no matter what the merits of the language. The difficulties are lack of tooling. eg, no debugger - or only a rudimentary one, no static analysis, no refactoring, no advanced code browser. If the language is successful, these things come with time. When you develop an in-house language, you'll never get the advanced tooling that makes for a great software development experience. This, for me, was why I was surprised by Joel Spolsky's announcement of an in-house language. (Although, to be fair, these things didn't really exist of VBScript nor for PHP at the time Wasabi came to be.)

slantyyz 11y ago
Don't people create things like Wasabi all the time? Aren't tools like RubyMotion, Appcelerator and their ilk kinda similar to Wasabi in terms of what they do? You might even make the argument that Coffeescript is somewhat similar to Wasabi.
wvenable 11y ago
I think your bracketed comment says it all; there was no obvious alternative at that time which would satisfy the market conditions. The VBScript version was super easy to install for most companies with the servers they already had available. They had a selling feature which was entirely dependent on this terrible technology. So they mitigated it. It's all pretty reasonable.

cjensen 11y ago

Replacing Wasabi code with the prettified output of Wasabi seems like a terrible idea to me. Is the result similar enough to the original source that it will still make sense? Do comments get preserved? Programmers just love to change good working code into the new style or new language. One has to always view the impulse to change skeptically.

krallja 11y ago
I'll make sure to include some example output in my next article. It's pretty readable - not quite idiomatic C#, but you can almost always see what's going on. It's very conservative C#, and it still uses the same style of coding that the original source used - ADO and `Response.Write`, rather than WebForms or ASP.NET MVC. This project had the full support of the company, from our newest hires all the way to Joel and Michael. As many people have noted, using this wacky one-off language was a source of a lot of friction in our business, and we felt that spending a few months to get rid of that friction would be a good use of resources (me).

brlewis 11y ago

We hadn’t open-sourced it, so this meant any investment had to be done by us at the expense of our main revenue-generating products. While we were busy working on exciting new things, Wasabi stagnated. It was a huge dependency that required a full-time developer — not cheap for a company of our size. The way I read this article, creating Wasabi a decade ago was not a mistake, given what they were doing and what was available at the time. Not open-sourcing Wasabi was a mistake, though.

gecko 11y ago
I agree. Especially when we first had Wasabi, there were a lot of other legacy ASP code bases lying around, and I think we could've both helped ourselves and gotten more community support by going that route. But it's also worth remembering this was before GitHub; this would've meant a SourceForge account, mailing lists, etc.—a reasonable extra use of resources. It wasn't as trivial a decision then.

Udo 11y ago

> Building an in-house compiler rarely makes sense. I disagree. First of all, Wasabi solved a real problem which doesn't exist anymore: customers had limited platform support available and Fog Creek needed to increase the surface area of their product to cover as many of the disparate platforms as possible. Today, if all else fails, people can just fire up an arbitrarily configured VM or container. There is much less pressure to, for example, make something that runs on both ASP.NET and PHP. We are now in the fortunate position to pick just one and go for it. Second, experimenting with language design should not be reserved for theoreticians and gurus. It should be a viable option for normal CS people in normal companies. And for what it's worth, Wasabi might have become a noteworthy language outside Fog Creek. There was no way to know at the time. In hindsight, it didn't, but very few people have the luxury of designing a language which they know upfront will be huge. For example, Erlang started out being an internal tool at just one company, designed to solve a specific set of problems. Had they decided that doing their own platform was doomed to fail, the world would be poorer for it today.

marktangotango 11y ago
>> Second, experimenting with language design should not be reserved for theoreticians and gurus. It should be a viable option for normal CS people in normal companies. One might think so, if one is charitable toward the typical developer and they're abilities. I worked at a place that had implemented their own query language and integrated it into their core product. The query language was interpreted, and walked structured text files stored on disk. Worked great for small installations, but as the company grew, acquiring larger clients, clients data corpi grew, performance fell of a cliff. The syntax of the language was all over the board, users would cut and paste to combine little recipes to do things, there was a never ending stream of support calls as to why this didn't work like this, and why couldn't this do this like this other part does that. Edit; wanted to say consistent, logical syntax is were someone with experience in language theory and implementation would have made an impact. The language as was, was the result of feature accretion. I think someone with knowledge would have attempted to craft a kernel of functionality, and back it with a more robust datastore (sql). Edit2: also want to clarify, the developers who did the implementation were actually quite talented, the project was simply not something they were equipped to deal with, and really weren't given the oppurtunity to refine or iterate on. Edit3: I offer this as an example of one company that implemented they're own langauge, of course the purpose of this example differs from wasabi, and is not intended to condemn or denigrate Wasabi, or Fogcreek. I guess it was a net win, but it was painful.

scotch_drinker 11y ago

Wasabi was technical debt. Like all forms of debt, there is productive and unproductive technical debt. Productive technical debt actually give some return on that debt. Unproductive technical debt doesn't. Given the fact that Wasabi lasted 10 years (and the company seems to have made a bunch of money because of it) and because Wasabi gave them the ability to adjust to market factors, I'd say the payoff from this technical debt was highly justified. All technical debt decisions should be made based on what the business hopes to get from the debt. Considerations for the alternatives, when the debt is retired, etc should all play a part. To globally say "this is a terrible idea" like so many in this thread are doing totally ignores these types of factors in favor of "It's a bad computer science" idea and thus miss the point of technical debt in the first place.

jfb 11y ago
It's not even remotely a bad CS idea, however. It's taking long established praxis with a sound theoretical background and applying it to a problem that that practice was intended to solve.

tptacek 11y ago

The author has graciously posted _Wasabi, The ??? Parts_, the internal book about Wasabi mentioned in the blog, on their website: http://jacob.jkrall.net/wasabi-the-parts/index.html http://jacob.jkrall.net/wasabi-the-parts/index.html Having now read it, I've come to the conclusion that the blog gives the wrong impression about the implications of having a custom language. Readers of the blog post come away with the idea that Wasabi was so full of "o.O" that someone was moved to write a book about that. In reality, the book is simply documentation of the language features, with callouts for weird interactions between VB-isms, ASP.NET-isms, and their language. You should definitely read the "Brief And Highly Inaccurate History Of Wasabi" that leads the document off. It's actually very easy now to see how they ended up with Wasabi: 1. The ASP->PHP conversion was extremely low-hanging fruit (the conversion involved almost no logic). 2. Postprocessing ASP meant PHP always lagged, so they started generating ASP from the same processor. 3. Now that all their FogBugz code hits the preprocessor, it makes sense to add convenience functions to it. 4. Microsoft deprecates ASP. FogBugz needs to target ASP.NET. They can manually port, or upgrade the preprocessor to do that for them. They choose the latter option: now they have their own language. It's step (3) where they irrevocably commit themselves to a new language. They want things like type inference and nicer loops and some of the kinds of things every Lisp programmer automatically reaches for macros to get. They have this preprocessor. So it's easy to add those things. Now they're not an ASP application anymore. Quick rant: if this had been a Lisp project, and they'd accomplished this stuff by writing macros, we'd be talking this up as a case study for why Lisp is awesome. But instead because they started from unequivocally terrible languages and added the features with parsers and syntax trees and codegen, the whole project is heresy. Respectfully, I call bullshit.

TheMakeA 11y ago
I agree. It also seems like they had a relatively straight forward migration path that worked out really well. Sounds like good decisions were made at the right times.
tedunangst 11y ago
Another perspective, if you're into wasabi history: http://www.tedunangst.com/flak/post/technical-debt-and-tacking-into-the-wind http://www.tedunangst.com/flak/post/technical-debt-and-tacki...

_pmf_ 11y ago

It's strange that the HN crowd, consisting mostly of developers who work for companies that exist on average for 16 months, has the audacity of calling Wasabi, a tool that has been in use for close to 15 years, a failure.

yellowapple 11y ago
Probably because it isn't some hipster badass ninja rockstar web-scale pipe-to-dev-null Wangular.js Ruby-on-Fails Web-2.0 SaaS app, and therefore automatically a failure.
- serve_yay 11y ago
  I disagree, it is exactly that. Badass ninja rockstars are exactly the people who decide to make this sort of thing. (Then they leave for the next thing, like they always do, and their coworkers are left with a pile of "??????????????")
  - mwcampbell 11y ago
    What would you have done, given the starting point of a VBScript codebase, to bring it to Unix and later to .NET? Remember, it does no good to talk about what should have been, years before. You have to make the best decision with what you already have. In that light, writing a custom compiler for a variant of VBScript doesn't seem so bad.
    - serve_yay 11y ago
      If your point is that it was strategically necessary given the constraints at the time, that's fine with me. There are lots of terrible things that became strategically necessary due to the past decisions of business people. I still wouldn't want to have to learn this language, would you?
      - spc476 11y ago
        I would. I might not like it, but I can't say for sure now, not having used it. And you never know, there could be some good ideas lurking deep inside. I recently played around with Atari 2600 BASIC (which is quite possibly worse emulated than on a real system) but found that it had an incredible tracing mechanism I've never seen elsewhere. Also, you could control the speed of execution as the programs runs (imagine---running a program at full speed, then slowing down to watch exactly what happens). You won't know until you try. (http://boston.conman.org/2015/06/16.1 http://boston.conman.org/2015/06/16.1)

pablosanta 11y ago

Has Joel jumped the shark? http://blog.codinghorror.com/has-joel-spolsky-jumped-the-shark/ http://blog.codinghorror.com/has-joel-spolsky-jumped-the-sha... Related blog post from a couple of years ago.

lubos 11y ago
This is the first thing that came to my mind too.

serve_yay 11y ago

I guess this worked for them, for some value of the word "worked", but it always seemed like a bad idea to me.

narrator 11y ago

You could have just started on Java. I've worked on very large 15 year old Java enterprise code bases that are doing just fine. That language is so pathetically maintainable and the backward compatibility between JVM releases is very good. Microsoft seems like a moving target with how often they deprecate things.

davelnewton 11y ago

Isn't this exactly what everybody said when they announced Wasabi in the first place?

mixmastamyk 11y ago

Wow, rabbit hole is right... The first mistake was writing a web-app in VBScript (not VB) ?? I'm not even sure that's possible, it's such an awful, limited language. Probably required components written in C++? The developer who started that should have been fired as incompetent. These are the "B-players in a hurry" you should get rid of, that can cost your company millions. Then instead of cutting their losses, they doubled and tripled-down on it until they had their own language and sophisticated tools around it. Around this time, Django and Rails had been started already. And several decent cross-platform web frameworks were years old, such as CherryPy. Even PHP would have been a better choice. One of these could have been phased-in parts at a time to minimize disruption. Did I get this right? Because there are so many WTFs that I must have missed something.

willu 11y ago
VBScript is the language of Classic ASP. Many, many sites were written with that technology ~15 years ago and some are still around. An unpleasant language, yes, but certainly not an incompetent decision at the time.
wvenable 11y ago
VBScript was literally the prescribed way of building web applications for IIS. This was a long time ago and things were way different than they were now. ASP was a revelation compared how web applications were built prior to it's introduction. It seems archaic now but those were archaic times.
- mixmastamyk 11y ago
  I seem to remember numerous frameworks being around for quite a while at that point. They could have used Thistle to move to PHP ten years ago and saved a lot of money.
tghw 11y ago
First, Classic ASP was equivalent to PHP in many ways. VBScript was the functional part of ASP. Go read more before you criticize: https://en.wikipedia.org/wiki/Active_Server_Pages https://en.wikipedia.org/wiki/Active_Server_Pages Second, the "developer who started that" were the founders. One had worked at Microsoft, and so was very familiar with ASP. Third, FogBugz was a complex, mature application by the time Django or Rails were even considerations for production systems. Phasing in in parts is not really a viable solution either. There was a lot of business logic written and shared that those new parts would need access to, which would create more work to implement. In short, no, you did not. You're looking at decisions made 10 years ago through today's lens, without considering the state of the art at the time. (In case you're wondering, I worked at Fog Creek from 2005-2012, though I was never a part of the FogBugz team.)

10098 11y ago

I wonder how much time and money they would save if they had just bitten the bullet and rewritten the entire thing in PHP in the first place instead of doing what they did.

wvenable 11y ago
The big advantage of the ASP/VBScript version is that there were almost no dependencies and it would install on the most basic IIS setup. Many companies already had IIS installed and configured but not doing anything. Getting companies to install PHP on Windows (a dicey position those days) was a non-starter.

Lazare 11y ago

It's fascinating, because writing your own custom language is one of those things that everyone knows is a bad idea. It's one of those things that people do because it seems like the path of least resistance (and in the short run, is), but it inevitably snowballs into a pit of technical debt. Spolsky knew this quite well (he'd written eloquently on the subject). ...and yet he still did it. His defence was that it was the easiest option in the short term, and he was probably right, but it doesn't matter. People only do stupid stuff that seems smart; saying "this stupid thing seems smart!" is only a defence if you have no idea that it's actually fundamentally stupid. Of all the people in the world, Spolsky is one of the least able to mount this defence. Contemporaneously with his decision to go all in on Wasabi, he wrote a scathing condemnation of Ruby for being slow, unserious, obscure; he suggested that a serious company shouldn't opt for Ruby because it was risky, and that choosing it would put you at risk of getting fired. Was he right? In 2006, maybe? I mean, he turned out to be wrong, but I don't think it was entirely obvious that Ruby was a serious choice 15 years ago. Of course, he wasn't writing 15 years ago, but even nine years ago, a very conservative, safe approach to choosing a technical stack very possibly did mitigate against selecting Ruby, for all the reasons he outlined. But those arguments applied twice as hard to Wasabi. You don't get to argue that there "just isn't a lot of experience in the world building big mission critical web systems in Ruby" (and hence you shouldn't use Ruby), and then turn around and use Wasabi for your big mission critical web system. Of all the people in the world, Spolsky probably had the best understanding of why Wasabi was a stupid, short sighted decision. He did it anyway. And it was stupid and short sighted. Rarely is someone so right and so wrong about the same thing at once. (And yes, Fogcreek is still around, and so is FogBugz. But I don't buy for a moment that Wasabi was actually a good choice. They survived it, but they didn't benefit from it.) Edit: Spolsky has written too much about why things like writing something like Wasabi is terrible idea to link it all. Besides, a lot of it has been linked in other comments. But I don't think I can express strongly enough that my anti-Wasabi position is simply repeating the things the guy that signed off on developing it and using in production wrote. ...then he decided to write a new language because apparently Ruby was too slow to possibly use to generate a graph, and there was literally no alternative to using Ruby for graph generating than writing your own compile-to-VBScript/PHP language. Words fail.

bootload 11y ago

"the fact remains that we had a Classic ASP application running on Linux and we didn’t have to pay anybody for the privilege." [0] Commercial reasons dictated why Wasabi was created and retired. Bravo Joel. [0] http://jacob.jkrall.net/wasabi-the-parts/introduction.html http://jacob.jkrall.net/wasabi-the-parts/introduction.html

overgard 11y ago

One thing I've always wondered (and I don't intend this as a criticism per se), but why didn't they open source it? If it had a following outside of Fog Creek it might not have been an inevitable dead end. While I hesitate to endorse a language based on VBScript, it seems like the extensions they added to it were pretty nice. I mean, if you're inclined to use a VBScript style language, Wasabi wasn't horrible, and given Spolsky's following and Fog Creek's mindshare, it seems at least possible it could have become a useful thing rather than a legacy thing to be replaced. I mean, at the very least, it's probably not worse than PHP. (Granted: my opinion of PHP is very low). Maybe it's for the best though, the world is probably better off without new wasabi projects.

krallja 11y ago
Looking back, I regret not open sourcing it as well. Pre-.NET, we didn't want to spoil our cross-platform competitive advantage. Post-.NET, we didn't think there was much of a market for a VBScript-to-C# transpiler (wouldn't those people prefer VB.NET?), and besides, open sourcing it seemed like a lot of work for basically no benefit.
- overgard 11y ago
  I get that, running an open source project can be very time consuming and expensive, and once it starts it becomes a part of your brand that cannot necessarily easily be dismissed. So it may have been wise not to open source it. I do think though, that wasabi was not obviously stupid or anything, and it probably could have had some amount of success in the wild.