
Killing Off Wasabi - GarethX
http://blog.fogcreek.com/killing-off-wasabi-part-1/
======
tptacek
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.

~~~
tedunangst
Another perspective, if you're into wasabi history:
[http://www.tedunangst.com/flak/post/technical-debt-and-
tacki...](http://www.tedunangst.com/flak/post/technical-debt-and-tacking-into-
the-wind)

~~~
lt
Wow, something clicked while I was reading that. Wasabi is the result of
following "Things You Should Never Do [1]" as a motto. Not that it's a bad
thing (it's not), but it just explains so much.

[1]
[http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html)

~~~
SiVal
Yes, I noticed that this story was a parable of what happens when a
charismatic leader declares something taboo, because of all the unforeseen
problems it always causes, so the acolytes resort to a workaround that has the
same problems in a different form but does not violate the religious taboo.

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.

~~~
gknoy
I disagree. Joel's "Don't rewrite from scratch" mantra seems like pretty solid
risk-avoidance, given his first-hand experience with that path.

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.

Thistle came out TEN YEARS ago, and Wasabi isn't much younger. Choosing the
path they did arguably contributed to them being able to survive this whole
time - and, having read Joel's creed on rewrites, I'm not sure they'd have
done better if they rewrote as Python or Javascript.

~~~
TheOtherHobbes
That was my take on it.

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.

~~~
stumacd
I'm not sure the 'there's no such thing as bad publicity' works when you're
aiming to come across as a voice of reason in the software community.

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.

------
Udo
_> 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
>> 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.

~~~
Udo
Those might all be true and it's understandable why nobody wanted to support
all that long term, but that doesn't mean people should abstain from
developing their own languages and platforms, just because it lead to nasty
code that one time at Fog Creek. And it's a "failure" that - from what I can
tell - was a pretty good business decision at the time. But even if you
discard that, even if you assert this was nothing but badness with no upside
whatsoever, it would still be a learning experience.

When a rider falls off a horse, they have to make a decision: abandon the idea
of horse riding ("riding your own horse rarely makes sense"), or apply that as
a lesson to your skill set and re-mount. While there is nothing wrong in
deciding that, upon reflection, horse riding was not for you, I think it's
harmful to go out and announce to the community that riding your own horse
rarely makes sense and should be left to the pros. Because what you're left
with then is a world where the only riding is done by dressage performers.

(Sorry, that analogy got a bit out of hand, and admittedly I know nothing
about horses, but I hope the point is still discernable)

~~~
marktangotango
Upon further reflection, I'd say that for the company in question, for that
particular sector, having the query language available was a positive
differentiator in the marketplace. I think it's clear Fogcreek's use of
wasasbi was necissitated by the business and tech climate of the time. So
clearly there are compellings reasons to go down this path.

I'd also say that languages are hard, runtimes are hard, languages and
runtimes together are really hard. A decision to go down this path should be
carefully considered, and not because a developer on staff read Parr's Antlr
book and wants to try it out.

~~~
relaytheurgency
I work for a company that has the same thing. They have, basically, their own
version of SQL. Clients can write scripts and import them. Lots of issues
supporting it. I wonder how small the world is.

------
zak_mc_kracken
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).

~~~
tptacek
It has always struck me as extremely bizarre that computer science graduates
would recoil from someone solving a business problem using what appears to be
very basic compiler theory.

The second half of your comment transitions from weird to mean-spirited, as
you begin speculating about people you don't know and their reasons for
changing jobs. I'm a little confused as to why you've been voted up so high on
the page.

~~~
jerf
I still think the fact that even most people with a 4-year degree still
haven't done a compilers course is the core problem. Both other times we've
had this discussion I haven't noticed anyone popping up to say "Yeah, I've
written like 3 compilers and Wasabi was just an insane idea." (Of course, the
Internet being what it is, someone will probably say that now. But the point
is I haven't seen it before I asked for it.) A lot of people are doing the
cost/benefit analysis with an order of magnitude or two too much in the "cost"
column. Yeah, of _course_ it looks insane then... but the problem is the
analysis, not the reality.

Compilers just aren't that magically hard and difficult. I'll cop to not
having written a true compiler yet but I've written a number of interpreters,
and I've written all the _pieces_ several times (compile to AST, interpret,
serialize back out, just never had the whole shebang needed at once).

If you're reading this, and you're still in a position where you can take a
compilers course, _take it!_ It's one of the most brutally pragmatic courses
in the whole of computer science and it's a shame how it's withered. (Even if,
like me, you'll probably write more interpreters than compilers. And nowadays
you really ought to have a good reason not to pick an existing serialization
off-the-shelf. But it's still useful stuff.) It's one of those things that is
the difference between a wizard and a code monkey.

(If I said that too concisely for your tastes, see: [http://steve-
yegge.blogspot.com/2007/06/rich-programmer-food...](http://steve-
yegge.blogspot.com/2007/06/rich-programmer-food.html) )

~~~
nostrademons
I've written like 3 compilers, and while I don't think Wasabi was quite
_insane_ (they had an interesting set of constraints, so I could at least
follow the logic), it's not the choice I would've done. Or rather, it's
totally the choice I would've done as a fresh college grad in 2005 having
written my first compiler for work (which was ripped out in about 2
months...it didn't take me that long to realize my mistake), but it's not what
I would've done with the hindsight experience of that and other compiler
projects.

The cost of an in-house programming language isn't in writing the compiler.
It's training all your new team members in the language. It's documenting the
language constructs, including corner cases. It's in not being able to go to
Stack Overflow when you have problems. It's in every bug potentially being in
either your application code, your compiler, or your runtime libraries, and
needing to trace problems across this boundary. It's in integrating with 3rd-
party libraries, and in not being able to use tooling developed for an
existing mainstream language, and having to add another backend to every other
DSL that compiles to a mainstream language.

All that said, I agree that if you're ever in a position to take a compiler
course, do it. It's one of the most valuable courses I ever took, and really
peels back the mystery on why programming languages are the way they are. It's
just that the difference between wisdom and intelligence is in knowing when
_not_ to use that brilliant technique you know.

~~~
jerf
"It's just that the difference between wisdom and intelligence is in knowing
when not to use that brilliant technique you know."

Which is precisely why I've never written a full compiler, even though I've
written all the pieces many times.

For instance, instead of writing a parser, could you perhaps get away with
just a direct JSON serialization of some AST? Do you really _need_ to emit
something, or will an interpreter do? So far I've never been so backed against
the wall that I've actually needed a full compiler.

~~~
nostrademons
Yeah, one of the compilers I wrote just used JSON as the AST, with it being
generated by a GUI interface. Another used HTML with annotations (although go
figure, I wrote an HTML parser [1] for it, because there weren't any C++
options at the time that didn't bring along a browser engine). A third had a
custom front-end but then emitted Java source code as the back-end.

The interesting thing is that the more experience you get, the more
alternatives you find to writing your own language. Could you use Ruby or
Python as the front-end, much like Rails [2], Rake [3], or Bazel [4]? Could
you build up a data-structure to express the computation, and then walk that
data-structure with the Interpreter pattern? [5] Could you get away with a
class library or framework, much like how Sawzall has been replaced by Flume
[6] and Go libraries within Google?

In general, you want to use the tool with the least power that actually
accomplishes your goals, because every increase in power is usually
accompanied by an increase in complexity. There are a bunch of solutions with
less power than a full programming language that can still get you most of the
way there.

[1] [https://github.com/google/gumbo-parser](https://github.com/google/gumbo-
parser)

[2] [http://rubyonrails.org/](http://rubyonrails.org/)

[3] [http://rake.rubyforge.org/](http://rake.rubyforge.org/)

[4] [http://bazel.io/](http://bazel.io/)

[5]
[https://en.wikipedia.org/?title=Interpreter_pattern](https://en.wikipedia.org/?title=Interpreter_pattern)

[6]
[http://pages.cs.wisc.edu/~akella/CS838/F12/838-CloudPapers/F...](http://pages.cs.wisc.edu/~akella/CS838/F12/838-CloudPapers/FlumeJava.pdf)

------
adnam
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)

~~~
jameshart
From the guy who founded an entire development ecosystem out of the web
framework he built on what was, at the time, an obscure Japanese programming
language, that he originally built for a project management application, it
seems kind of strange that he'd be surprised that someone might build a
complex tool in similar circumstances.

In a parallel world where the cool developers were all attending Wasabiconf,
Joel Spolsky Prime wrote a sneering blogpost assuming that DHH Prime was
joking about the crazy 'scaffolding' and 'proprietary database mapping'
framework he was building BaseCamp on

~~~
blub
I would like to remind you that we are talking about Ruby vs essentially
VBScript. I mean, I pretty much hated the Ruby hype and especially the
attempts to make it seem better than it really was, but we are indeed talking
here about web software written in VBScript that ran only on Windows. For many
people working with web tech today, that is inconcievable. Not that it didn't
have its fair share of detractors back then...

Hats off to FogCreek for building a successful product, but that doesn't mean
that people have to admire or even accept their technical choices without any
criticism. I for one consider DHH's criticism to be on mark.

------
Marazan
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

~~~
scotch_drinker
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
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
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
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.

------
scotch_drinker
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
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.

------
_pmf_
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
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
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
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
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
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))

------
brlewis
_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
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.

------
stevoski
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
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.

------
protomyth
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
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
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.

------
mwcampbell
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
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
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
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.

------
chkuendig
Related from Jeff Atwood: [http://blog.codinghorror.com/has-joel-spolsky-
jumped-the-sha...](http://blog.codinghorror.com/has-joel-spolsky-jumped-the-
shark/)

It's funny how they teamed up 2 years later to build stack overflow (and again
used an MS stack)

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

~~~
krallja
Wasabi: The ??? Parts

[http://jacob.jkrall.net/wasabi-the-parts/](http://jacob.jkrall.net/wasabi-
the-parts/)

~~~
tptacek
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. :)

------
cjensen
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
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).

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

~~~
krallja
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
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.

------
overgard
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
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
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.

------
noir_lord
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
They got almost 10 years out of it. Even with accumulating technical debt,
that reads like a success to me.

------
pablosanta
Has Joel jumped the shark?

[http://blog.codinghorror.com/has-joel-spolsky-jumped-the-
sha...](http://blog.codinghorror.com/has-joel-spolsky-jumped-the-shark/)

Related blog post from a couple of years ago.

~~~
lubos
This is the first thing that came to my mind too.

------
userbinator
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)

------
bootload
_" 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)

------
narrator
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.

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

~~~
ygra
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
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?

------
10098
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
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.

------
tempodox
_Building an in-house compiler rarely makes sense._

Dang, it's significantly less entertaining but I'm afraid he's right.

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

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

------
robotnoises
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
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
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

~~~
ad_hominem
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.

------
Lazare
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.

------
mixmastamyk
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.

~~~
tghw
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.)

~~~
mixmastamyk
As I mentioned PHP was pushing 10 years old at that point. They already had
built a translator to it "Thistle", so they could have gone to PHP at that
time, just like they mention going to C# now.

I'm not a huge PHP fan, but it would have saved 10 years of development and
maintenance over their NIH solution. See the "Jumped the Shark" piece from
Coding Horror... not a minority opinion.

