Was just switching to PHP out of the question? If you’re compiling to PHP anyway and all the translated code is correct enough to ship to customers, why not just spend the time making the translator output code in a nice format, spit out one final version, then clean it up by hand and you’re now on PHP for the future. Works on many platforms, syntax is close enough that VB programmers could continue working on it in PHP, they could hire PHP developers, etc. And all without writing the Second System in which they do everything by hand and introduce new bugs.
Go did that with their switch to rewriting their compiler in Go - a program translated the C code into Go and once they got it in good enough shape, they had ugly Go code to work but it produced the same thing. Then they just cleaned it up, did some hand optimizations of things, and now they’re on Go going forward.
That question would have been before my time, and it’s possible nobody even asked it. The first task was simply to put the bugz on linux. Translate into something else and then get that running back on Windows may not have been obvious. But I can try to answer anyway.
I think an ASP based deliverable was better for Windows systems. I’m not sure what was really involved with installing PHP and integrating with IIS in 2005, but I would wager it was harder than installing ASP.
Generally, I think customers are wary of being the second class citizen, and giving the existing (at the time 100%) Windows base a PHP app would give that impression. Also, people had source access and a fair number had made modifications. It would have been turbulent for no customer benefit.
Depending on how the compiler worked, that could be out of the question. If it was designed to make relatively nice PHP code, it could be possible, but if it worked more like a C->javascript compiler, using PHP more as a form of assembly rather than trying to translate it into pretty code, it could be completely out of the question without a major overhaul of how the compiler works.
He says: “Even though PHP is available for Windows, it’s not preinstalled, and I don’t want to pay engineers to help all of our Windows customers install PHP. We could use .NET, but then I’d have to pay engineers to install Mono for all our Unix customers, and the .NET runtime isn’t quite ubiquitous on Windows servers.”
So “PHP only” wasn’t an obvious choice at the time for a significantly-windows userbase.
There’s a lot of the original rationale in there too.
Oh, hey, soy sauce got mentioned! Some further thoughts from before about wasabi: http://www.tedunangst.com/flak/post/technical-debt-and-tacking-into-the-wind
Was just switching to PHP out of the question? If you’re compiling to PHP anyway and all the translated code is correct enough to ship to customers, why not just spend the time making the translator output code in a nice format, spit out one final version, then clean it up by hand and you’re now on PHP for the future. Works on many platforms, syntax is close enough that VB programmers could continue working on it in PHP, they could hire PHP developers, etc. And all without writing the Second System in which they do everything by hand and introduce new bugs.
Go did that with their switch to rewriting their compiler in Go - a program translated the C code into Go and once they got it in good enough shape, they had ugly Go code to work but it produced the same thing. Then they just cleaned it up, did some hand optimizations of things, and now they’re on Go going forward.
That question would have been before my time, and it’s possible nobody even asked it. The first task was simply to put the bugz on linux. Translate into something else and then get that running back on Windows may not have been obvious. But I can try to answer anyway.
I think an ASP based deliverable was better for Windows systems. I’m not sure what was really involved with installing PHP and integrating with IIS in 2005, but I would wager it was harder than installing ASP.
Generally, I think customers are wary of being the second class citizen, and giving the existing (at the time 100%) Windows base a PHP app would give that impression. Also, people had source access and a fair number had made modifications. It would have been turbulent for no customer benefit.
Depending on how the compiler worked, that could be out of the question. If it was designed to make relatively nice PHP code, it could be possible, but if it worked more like a C->javascript compiler, using PHP more as a form of assembly rather than trying to translate it into pretty code, it could be completely out of the question without a major overhaul of how the compiler works.
In the original article from Joel on Wasabi:
http://www.joelonsoftware.com/items/2006/09/01b.html
He says: “Even though PHP is available for Windows, it’s not preinstalled, and I don’t want to pay engineers to help all of our Windows customers install PHP. We could use .NET, but then I’d have to pay engineers to install Mono for all our Unix customers, and the .NET runtime isn’t quite ubiquitous on Windows servers.”
So “PHP only” wasn’t an obvious choice at the time for a significantly-windows userbase.
There’s a lot of the original rationale in there too.