From the comments on the article:
"However, instead of upgrading to ASP.NET, they decided to.. write their own proprietary language that compiles down to VBScript/PHP/JavaScript."
Atwood then goes on to call it "crazy town."
Am I the only one who thinks that this decision might've paid off down the road for them? It sounds like he was just trying to code his app in a way that it would work in multiple types of server stacks, rather than trusting that MS wouldn't break their backwards compatibility again after doing so with ASP.net.
Maybe I'm wrong. I'm curious what the people who know way more than me think about this. I knew next to nothing about web apps in 2006, other than dabbling in PHP as a side note in a MySQL class.
By way of background -- at the time that we created Wasabi's predecessor, Thistle, we had a large code base in VBScript that only ran on Windows, and almost no developers. Thistle was done by a summer intern in eight weeks and got us PHP FogBugz running on Unix for 8 weeks work, which almost doubled our potential market.
At the time, Fog Creek consisted of three people and one summer intern. We couldn't afford to rewrite all of FogBugz in some other language... even if there was a language (in 2003) that was reasonably portable between Windows and Unix, which there wasn't. (Yes, we considered PHP. That would still have been a full rewrite, and PHP on Windows was crappy and increased the system requirements in a way that our customers wouldn't have liked).
Yeah, a Lexus is better than a Camry, but not everyone can afford Lexuses. So saying "you idiot, why are you driving that crappy car, it's obviously crappy" is not particularly insightful... the question is, if you can get 90% of the bang for 10% of the bucks, that's a pretty good decision as a startup, even if it seems strange.
What's more interesting about the reaction is that so many average programmers seem to think that writing a compiler is intrinsically "hard," or, as Jeff wrote in 2006, "Writing your own language is absolutely beyond the pale." To me this sounds like the typical cook at Olive Garden who cannot possibly believe that any chef in a restaurant could ever do something other than opening a bag from the freezer and dumping the contents into the deep fryer. Cooking? With ingredients? From scratch! Absolutely beyond the pale! Compilers aren't some strange magic black art that only godlike programmers are allowed to practice. They're something you learn how to create in one semester in college and you can knock out a simple one in a few weeks. Whatever you think about whether it's the right thing or not, if you think that a compiler is too hard to do as a part of your day job, you may want to invest some time in professional development and learning more about your craft.
To anyone reading this who still is in college, I can't emphasize this enough: TAKE THE COMPILERS COURSE. Yes, it's hard, but it's one of the closest things you'll get to programming superpowers compared to your peers.
I haven't written a compiler since I took the course... but I've written a lot of interpreters. And as the course will teach you, they are used everywhere, for a lot of things, even things you wouldn't expect. An HTML renderer, for instance, is basically an interpreter for the language called HTML, interpreting it into graphics commands. (Adding JS to the mix complicates things, but that's a decent understanding of a straight-up HTML renderer.)
I think the neat thing I learned from my compilers class is that writing a compiler isn't insurmountable. The problem is, however, that writing a compiler for a full-featured language is quite an investment in time and thought.
Given that languages have developed quite significantly since 2006, if you had to make the same decision in this day, what would you do?
I learned more about the fundamentals of programming in one semester of compiler design than I did in the rest of 4 years of courses. It ought to be a requirement for any comp. sci. degre, IMO.
Well said. I like the cooking analogy. Part of the craft is enjoying what you do and pushing the limits, and you do that! Rails, Django, etc. may be practical, but using them takes some of the fun out of it.
It's interesting that in the linked post Atwood cites, as earlier evidence you may be jumping the shark, your (alleged) hatred of Java, a language designed to prevent programmers from hurting themselves by sucking. A lot of accepted wisdom in software engineering comes down to "you must use childproof safety caps because some of you are that stupid".
Java, of course, is so careful to protect global namespace that all kinds of "patterns" for disguising global state as something else emerged (woohoo "Singletons"), resulting in tools to find them and force them to be further disguised.
Another interesting thing (recall PG's aphorism that any sufficiently complex project contains a half-assed implementation of Lisp) is that designing ridiculously complex declarative syntaxes ("data") isn't considered beyond the pale on many projects (or at least it's allowed to happen through carelessness), but creating a properly defined language is.
I think you and Jeff absolutely deserve each other, and are both equally fucking mental. (btw, stopped reading both of your blogs years ago specifically because of trite shit like this)
> We had a large code base in VBScript that only ran on Windows, and almost no developers.
So you roll your own language to improve things?
> Yes, we considered PHP.
I don't think you did.
> That would still have been a full rewrite, and PHP on Windows was crappy and increased the system requirements in a way that our customers wouldn't have liked.
Full rewrite into a cross platform language which only went on to improve and would have been far more backwards compatible [with a small eventual migration to php5]. I'm sorry but the fact you can't write a decent install script or manual to get your system working in different environments is not reason enough to roll your own language. Yes developing the compiler didn't take long but now you have a zero'd recruiting pool, a slower debug loop and an eventual fragmented maintenance nightmare. Oh and by the way, saying "PHP on Windows was crappy" is not particularly insightful...
> Cooking? With ingredients? From scratch! Absolutely beyond the pale!
It is when you're working at McD's though, and that is what Jeff everyone else was trying to tell you.
> What's more interesting about the reaction is that so many average programmers seem to think that writing a compiler is intrinsically "hard,"
We didn't react because we're average and think writing a compiler is hard, we reacted because you went against every common sense principal of software development there is. Any idiot who completes a degree can build a compiler / code generator, that doesn't mean its a good idea for your next web app. But go ahead, call us "average" delude yourself more, everyone who doubts you is just stupid because, well you're just such a godlike programmer.
I don't get it, its obvious, you're an MS flake, because of that you didn't want to use the logical choice, PHP, so you did something stupid. And now you can't just own it, instead you going around insulting everyone who calls you out. The best developers own their mistakes and learn from them, the bad ones flail around, blame the language, system, or other people.
There's not much difference since generating the abstract syntax tree is usually the hardest part. Once you've done that, it's just a matter of generating a string representation for each node in the tree for the given target language.
Did you ever try to translate one language into another? Usually it's just generating the AST that is the hard part, then you can just spit out code and let the compiler for the target language do the hard stuff.
I'm not clear where people get this idea from. In the case of Wasabi specifically, it uses Code DOM, which can generate IL, C#, and VB.NET out-of-the-box, and can be extended fairly easily to target other platforms as well.
I have a theory about this. It has to do with the fact that Fogbugz started as off-the-shelf software, where companies would buy the CD and install the software on their own servers. The hosted version came much later.
Considering that most of the original code base was using ASP (there was no .NET when they started), this meant that all of their source code had to be shipped with the product. They couldn't just ship binaries. So part of me wonders if the Wasabi idea was a way for them to have obfuscation and some protection against piracy and competitor knock-offs.
I'm pretty sure it had more to do with supporting Windows and Linux server installs. I know we looked at FogBugz for an internal use, but at the time it was Windows only. Since we were a Linux shop, there was no way it was going to work.
I don't know... if Linux support was their only goal, there were other options that could be taken into consideration. I'm reasonably sure that around 2005 there were some solutions that made it possible to run ASP on Apache. At the time, even Mono/XSP was somewhat viable. [1]
Wasabi nowadays uses Mono, and until very recently, whether it was legitimately viable was a matter of opinion. Technically speaking, its garbage collector made it ill-suited to long-running processes (such as web servers), and its performance was far worse than the Microsoft CLR--frequently two to five times slower. Ideologically, we also met resistance; many Linux system administrators seem far more reticent to install Mono compared to PHP. Both have improved recently, but back in 2005, Mono was not a sane option.
Yeah, but I wouldn't have installed that on my server, it would have been too awkward and a support challenge for FogCreek. So, I think the idea was to support deployment on a standard runtime for each platform: PHP on Linux, ASP on Windows.
Atwood then goes on to call it "crazy town."
Am I the only one who thinks that this decision might've paid off down the road for them? It sounds like he was just trying to code his app in a way that it would work in multiple types of server stacks, rather than trusting that MS wouldn't break their backwards compatibility again after doing so with ASP.net.
Maybe I'm wrong. I'm curious what the people who know way more than me think about this. I knew next to nothing about web apps in 2006, other than dabbling in PHP as a side note in a MySQL class.