16 ms·

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 VBScr

by JPKab 14y ago

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.

noblethrasher 14y ago
Some people overestimate the difficulty in writing a compiler. A single developer could have probably done it in six to eight weeks (seriously).
- eksith 14y ago
  Well "compiler" in this case is really "high-level code generator" instead of "low-level code generator". So yeah.
  - noblethrasher 14y ago
    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.
    - chollida1 14y ago
      Really? I've worked on compilers for a long time and the AST generation is typically the easiest part. Optimizations, and different target backends are easily an order of magnitude harder. That's why every new language typically begins as a simple AST tree walker, that's the easy part. They can they "graduate" to byte codes and then to asm generation if appropriate.
      - DoubleCluster 14y ago
        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.
        chollida1 14y ago
        Hmm, for me it's always been tougher trying to determine what the source language should compile down into. AST generation is usually simple. It's the conversion to the other language that usually get's difficult.
      - c3d 14y ago
        Agreed. fortunately, there's LLVM for the back end now. And XL for the front end/AST
      - noblethrasher 14y ago
        That's fair. But in my world “compiler” and “optimizing compiler” are very different things. Also, targeting different backends is drudgery but I never thought of it as being hard.
        chollida1 14y ago
        > That's fair. But in my world “compiler” and “optimizing compiler” are very different things Ah, ok. In that case, I'd agree.
  - gecko 14y ago
    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.
spolsky 14y ago
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.
- perishabledave 14y ago
  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?
- jerf 14y ago
rglullis 14y ago
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.
- mbreese 14y ago
  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.
  - rglullis 14y ago
    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] [1]: http://www.codeproject.com/Articles/9738/Introduction-to-Mono-ASP-NET-with-XSP-and-Apache http://www.codeproject.com/Articles/9738/Introduction-to-Mon...
    - mbreese 14y ago
      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.
    - gecko 14y ago
      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.

by JPKab 14y ago

noblethrasher 14y ago

Some people overestimate the difficulty in writing a compiler. A single developer could have probably done it in six to eight weeks (seriously).

eksith 14y ago
Well "compiler" in this case is really "high-level code generator" instead of "low-level code generator". So yeah.
- noblethrasher 14y ago
  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.
  - chollida1 14y ago
    Really? I've worked on compilers for a long time and the AST generation is typically the easiest part. Optimizations, and different target backends are easily an order of magnitude harder. That's why every new language typically begins as a simple AST tree walker, that's the easy part. They can they "graduate" to byte codes and then to asm generation if appropriate.
    - DoubleCluster 14y ago
      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.
      - chollida1 14y ago
        Hmm, for me it's always been tougher trying to determine what the source language should compile down into. AST generation is usually simple. It's the conversion to the other language that usually get's difficult.
    - c3d 14y ago
      Agreed. fortunately, there's LLVM for the back end now. And XL for the front end/AST
    - noblethrasher 14y ago
      That's fair. But in my world “compiler” and “optimizing compiler” are very different things. Also, targeting different backends is drudgery but I never thought of it as being hard.
      - chollida1 14y ago
        > That's fair. But in my world “compiler” and “optimizing compiler” are very different things Ah, ok. In that case, I'd agree.
- gecko 14y ago
  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.

spolsky 14y ago

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.

perishabledave 14y ago
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?
jerf 14y ago

rglullis 14y ago

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.

mbreese 14y ago
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.
- rglullis 14y ago
  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] [1]: http://www.codeproject.com/Articles/9738/Introduction-to-Mono-ASP-NET-with-XSP-and-Apache http://www.codeproject.com/Articles/9738/Introduction-to-Mon...
  - mbreese 14y ago
    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.
  - gecko 14y ago
    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.