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.
It's a good case study in market segmentation, though. Lisp works because all of the programmers who would like to do language design as part of their day job gravitate to it. As a result, it has the most advanced language features of any language on the planet. All of the programmers who just want their programming language to be a stable, dependable tool they can use gravitate to other languages (tops among them: Java and Go), and they build some pretty cool products with them because they aren't distracted by improving the language. Wasabi's big failing is that it tried to introduce Lisp-like concepts to programmers who have to work in ASP and PHP in their daily jobs. It's kind of a no-man's land there.
There is inevitably a Law of Conservation of Coding Cost that will get you one way or another. If you won't rewrite your code from scratch (because of all the unrecognized wisdom in the old code), you'll build a compiler from scratch (and discover all the unrecognized wisdom in proven compilers), or you'll switch to some proven cross-platform solution that will cover most of your needs, but the remaining pieces needed to complete the job, when added together, will introduce you to all the unrecognized wisdom embodied in the standard, platform-specific toolchains, or some other approach that will preserve the cost in some other way.
This "never rewrite from scratch" dogma is an example of incomplete wisdom.
The cost to build and maintain Wasabi was surely higher than rewriting as X, but the risk sounds substantially less, and effectively spreads the risk part of technical debt over future years.
A bad rewrite could have killed the company. Historically, rewrites do not have a good delivery record.
A sideways sort-of-DIY ever-expanding transpiler-or-whatever kept the project alive and profitable.
Sometimes an ugly hack is the right answer if it keeps the money coming in.
Also, valuable PR.
I think the discussion could have been nipped in the bud if it was described similarly to your summation - a necessary business decision rather than good software practice.
Here they did not rewrite from scratch they developed a bridge that allowed them to keep moving forward as the world that the old software was based on disappeared. And now they are on the other side with a code-base that works and has been providing cash-flow the whole time.
but, and maybe they were also recompiled, did you keep your tests as well?
A few of the oldest FogBugz tests are in `unitTest.asp` and were written in Wasabi. They got transpiled over to C# like everything else. Some are confirming Wasabi language features (e.g. `testLambda`, `testDictionary`, `testErrorHandling`), so I could remove them.
All of Wasabi's unit tests were deleted with Wasabi.
I'm very curious, would be grateful for an answer! tx
Roslyn is an open-source implementation of the entire C# compiler, with some fantastic design decisions that allow you to use it in pieces or all together. https://github.com/dotnet/roslyn I used the C# generator portion of the platform.
Thanks for posting.
<title>An Example Wasabi Program</title>
<h1>An Example Wasabi Program</h1>
<p>Arithmetic: 1 + 1 = <%= 1 + 1 %></p>
<p>Dynamic Content: x + y = <%= IntRequest("x") + IntRequest("y") %>
Before rich client/ajax took off, it was more than adequate for most e-commerce, web publishing, and internal administrative applications. Truth be told, it still is, but it's just soooo 2001.
Public Abstract Class Animal
Abstract Function Speak() As String
Overridable Function Eat() As String
Public Class Dog Inherits Animal
Override Function Speak()
Override Function Eat()
Return Base.Eat() & " Woof!"
Without that, you'd have to rewrite, in which case, why not rewrite in an existing language?
I suspect that many of the armchair critics can't relate to being constrained by decisions made years ago at the start of a project -- decisions that one might now regret but nonetheless constrain the way the codebase can evolve.
At the point you've decide to build a terrible new internal-only language just to maintain a single bug-tracking app codebase ... perhaps you aren't been doing an accurate cost/benefit analysis?
You've also got several current and former FC'ers on this thread, all? of whom don't like Wasabi as a language, all saying that from a pure cost/benefit perspective, Wasabi paid off.
Agreed! But I would consider that an argument against using macros, not an argument for Wasabi.
Interestingly, since new hires were supposed to be pretty smart and had to pay the cost of learning Wasabi anyway, they could have just taken a page from Paul Graham and gone with Lisp. The learning curve should be the same (or easier, given the amount of material available) and they would have crazy good compilers and libraries from day one.
I think we are missing a piece of the puzzle somewhere.
"Designing Active Server Pages -
Scott Mitchell's Guide to Writing Reusable Code"
I'm not sure when I bought it, but it came out in 2000. Around that time, I'd seen some pretty nasty php, not much asp (but enough VisualBasic to start looking for a pitchfork whenever I saw it mentioned) -- and shortly after I worked as a sys.admin. at a place with a significant investment in Coldfusion (arguably the first php/asp-style language).
I've yet to write any classical ASP, and do anything more than glance at newer .net and what-not -- but I still got a lot from that book.
It, along with some of the posts I found on the Coldfusion fusebox framework/pattern did a lot for helping me keep the difference between "bad language" and "bad programmer" straight.
Just because most all php code I've seen is crap, doesn't mean all php code is crap. And it didn't have to be in the early days either.
Another fun book that's somewhat related (in my mind anyway) is:
"Program Generators with XML and Java"
by J. Craig Cleaveland (Prentice-Hall, 2001)
(Sometimes one finds great technical books on sale, too!)
I was so sad, thinking about how using a cross-platform Lisp (I.e., LispWorks) would have solved this problem for them by design. FogCreek has some pretty smart folks, it should have been within their reach to use LW and go...
The code they start with (a) works and (b) is fiddly.
To rewrite it a better language, (b) means they will very likely lose many months to problems with (a).
So, it makes more sense for them to transpile and preserve the fiddley bits than it does for them to rewrite.
That is to say, it seems like they did choose the better technology stack for the job at hand. If you're going that direction, the real problems started when Joel got a job at Microsoft.
This is where I'm curious that they didn't just start writing PHP from that point forward. It was already a cross-platform language. And, if I recall, had a lot of hype and was gaining traction fast I'm the late 90's and early 2000's.
Certainly hindsight is 20-20, but I remember a lot of folks betting big on PHP at the time.
Sounds like good decisions were made at the right times.