An interesting point from that, since everyone likes to bash Wasabi:
> "If we hadn't done Wasabi, then we'd have had to rewrite all of FogBugz, and that would've killed the company. Wasabi also gave us stuff that developers are only now rediscovering, like code that executes on both client and server (e.g. via server-side/client-side React), that even gave us a development edge. I've written about this at length (https://news.ycombinator.com/item?id=9779133) and won't revisit it, but while I think that Wasabi targeting .NET may have been a mistake, Wasabi itself was not a mistake."
great post and it changed my perspective on what wasabi was. This part makes complete sense:
Working on FogBugz changed my perspective on technical debt. I used to believe, as I suspect many do, that it was strictly a bad thing. You took a shortcut because you’re lazy, and then it comes back later to bite you. Count how many times that Wikipedia article uses the word “lack”. As the originator of the term Ward Cunningham explains, that’s off the mark. Buying something with credit doesn’t automatically imply you’re not going to pay your bills.
Instead of thinking of technical debt as yesterday’s work that I failed to do, I think of it as tomorrow’s feature I can have today. You have to pay interest, but in the mean time you’re shipping a product, have a roof over your head, and are keeping the lights on. A much hipper programmer might say something like “you ain’t gonna need it.”
In one sense, Wasabi was a rather substantial payment on the debt we had accumulated. FogBugz was written in a now dead language. Building a compiler extended the life of the product, though of course now we had to pay for the compiler, too. So maybe it was more like a bridge loan, or refinancing. The financial wellbeing of Fog Creek at the time depended on FogBugz, so a total rewrite would have been a terribly risky investment. Even if it costs more in the long run, spreading those payments out over time gets you a lot of stability.
while I also enjoyed Coding Horrors: Has Joel Spolsky Jumped the Shark?[0], Jeff either missed this point or ignored it on purpose to support the shark-jump theory
i thought wasabi was an excellent idea when i first read spolsky's post about it, and nothing i've heard since has changed my mind. these days, when i see it blamed for any of fogcreek's problems, i simply see it as a sign that the commenter is unfamiliar with the issues involved.
As far as technology related, I listen to Coding Blocks, RunAs Radio, Hanselminutes, Software Engineering Radio, Herding Code, .Net Rocks. Always looking for more though.
What I always fail to understand about Wasabi: why did they keep the code in the source language and compile to CLR object code, instead of running the same parser with a different codegen target, to transform the PHP wholesale into valid C# once, and then overwrite the codebase with that?
Do you really want to inherit autogenerated code? I doubt the autogenerated C# would be nearly as easy to understand or read as the original Wasabi code. I also think writing CLR object code, if it's anything like writing assembly, would be much easier to generate than C#.
Well, it is what they eventually did, after ten years. With tons of tweaks to make it spit out natural-looking outputs. I just don't understand why they didn't go that way from the start.
> to transform the PHP wholesale into valid C# once
I'm not quite sure what you mean; PHP was only ever a target; there was no source in PHP. It was something VBScript-esque being compiled to both ASP (later C#) for Windows and PHP for Linux. This started, of course, long before Mono.
They could have achieved the same (same code on client and server) if they had just written in JavaScript/JScript though. I bet JavaScript is also easier to translate to PHP and C# than VBScript. They also claim that Wasabi made it possible for them to add closures to VBScript. Cool, but again, using JavaScript from the beginning would have been a lot easier.
https://www.reddit.com/r/programming/comments/3n2sc1/why_fog...