Hacker News new | past | comments | ask | show | jobs | submit login

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

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.




If it had been a Lisp project, then Lisp programmers (and programming aficionados that have never used Lisp, but are attracted to its elegance) would be saying how awesome it is, and then most other developers would be talking about how they'd never work at Fog Creek because you have to use Lisp.

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.


Kind of a weird, cliche-informed rant here about lisp. To clarify, lisp simply offers functional programming by default and metalinguistic abstraction - most languages don't. So it tends to be used by people/organizations seeking higher-level organizational tools than functions/modules/classes or organizations looking to leverage functional paradigms. It's plenty stable and plenty dependable - just look at some of the names juxt has helped to adopt Clojure [1]. Or consider Netflix [2].

[1]: https://juxt.pro/#clients

[2]: https://speakerdeck.com/daveray/clojure-at-netflix


Except, clojure isn't LISP.


Another perspective, if you're into wasabi history: http://www.tedunangst.com/flak/post/technical-debt-and-tacki...


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


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.


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.


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.


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.


Problem with rewrites is there is the terrible gap that opens up between the old stuff which goes stale quickly, and the new stuff which isn't ready for prime time. Cash-flow then dries up right as the amount of work needed is maximal. Death follows quickly.

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.


I think it's related to the Waterbed Theory[1]. Or, put another way, there's no free lunch. The bill will be paid, either now or later, by you or someone else. You're probably better shifting responsibility than time...

1: https://en.wikipedia.org/wiki/Waterbed_theory


And yet... they ended up doing just that? But only after pouring tons of time and energy into not doing so.


At what point was FogBugz rewritten?


Presumably some time before they killed Wasabi? Am I misunderstanding at a fundamental what the heck Wasabi is?


Wasabi is a compiler. The output of Wasabi was C# code. One day, I deleted Wasabi and checked in the C# code. I did not have to rewrite FogBugz in the slightest.


Ohhh, I thought the target was CLR. I didn't realize it was a transpiler.


Ohhh, I thought the target was CLR. I didn't realize it was a compiler.

FTFY


transpiler ⊂ compiler


(lightbulb!)

but, and maybe they were also recompiled, did you keep your tests as well?


Most of them are NUnit tests, which don't care what source language the assembly under test is written in.

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.


In my (brief, haphazard) research for this article, I somehow missed this article. Thanks for sharing it. I really like the analogy with a bridge loan.


Given both the tedunangst's article and yours, I wonder what has happened to the JavaScript output feature? I don't seem to see it mentioned in your article? But I don't really know about Roslyn, so I'm not sure what it provides; does it have anything helpful? (I assume it has some kind of a C# generator; probably a C# parser too?), but - either you don't have a need for JS output anymore, or you've written a C#->JS translator? (Or used some 3rd-party one?)

I'm very curious, would be grateful for an answer! tx


See https://news.ycombinator.com/item?id=9780798 - I took the output of Wasabi's JavaScript generator and checked it in to source control. If someone wants to change the JavaScript, they have to do it manually, as there is no longer any program maintaining that code for them.

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.


At least you found the wiki page for soy sauce. :)


Actual, informational, thoughtful post from someone who has first-hand knowledge of an act of actual software engineering.

Thanks for posting.


So what happened to the JavaScript code that was compiled from Wasabi?


I would be fascinated to know as well. Either incrementally replaced before hand, or one shot translated?


It got checked in as-is. FogBugz Ocelot doesn't use it, so there's rarely any reason to modify it.


Oh. Ocelot was obviously a bigger technical change than I thought. You should write that up too. :)


I personally did not have anything to do with Ocelot, so I'll have to leave that to someone more qualified :)


Respectfully, their example code is the following:

  <%
  <WebEntryPoint("example.asp")> _
  Sub Example()
    %>
    <!DOCTYPE html>
    <html>
      <head>
        <title>An Example Wasabi Program</title>
        <meta charset="utf-8">
      </head>
      <body>
        <h1>An Example Wasabi Program</h1>
        <p>Arithmetic: 1 + 1 = <%= 1 + 1 %></p>
        <p>Dynamic Content: x + y = <%= IntRequest("x") + IntRequest("y") %>
      </body>
    </html>
    <%
  End Sub
  %>
I mean, they basically went to the trouble of building their own compiler to be able to keep writing Frankenstein ASP. If they'd built a language like Elixir I think people would be a lot more sympathetic.

http://jacob.jkrall.net/wasabi-the-parts/a_first_program.htm...


The thing is, "frankenstein asp" (and PHP) are so damn easy. Yeah it mixes presentation with logic and after a point it all gets really messy but on the other hand everything about a page is right there and you don't need to do any builds and you can code in notepad and deploy with xcopy/rsync.

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.


I love that he calls <%%> "tie fighters."


Thanks for the explanation! I had no idea what that phrase referred to.


Not sure I follow.


If you go to the trouble to write your own language, make it not terrible?

  Public Abstract Class Animal
    Abstract Function Speak() As String

    Overridable Function Eat() As String
      Return "Yum!"
    End Function
  End Class

  Public Class Dog Inherits Animal
    Override Function Speak()
      Return "Woof!"
    End Function

    Override Function Eat()
      Return Base.Eat() & " Woof!"
    End Function
  End Class
http://jacob.jkrall.net/wasabi-the-parts/classes.html#access...


It wasn't written that way to facilitate future spaghetti code, but to make sure the old stuff still worked.

Without that, you'd have to rewrite, in which case, why not rewrite in an existing language?


That isn't Classic ASP code, that's more .NET-ish stuff. So it wouldn't have required a rewrite to avoid it, right?


That's the ++ in the ASP++. Stock ASP/VB works (or worked) too, but lots of new syntax was added to support .net.


Another volunteer to rewrite all the existing ASP code!


He means if they were going to compile to ASP and PHP anyway, they could have at least gone with a better source language than ASP++.


ASP++ Was the path of least resistance given where they started, which was classic ASP and VBScript.

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.


The path of least resistance would have been to write the ASP-to-PHP transpiler, check in the PHP, and stop there.


That would, at a minimum, have created substantial turbulence on the windows side. Continuing to ship the same windows installer with the same system requirements was less resistance.


I can relate, for sure, but it's not like they'd written a 50 million line operating system in ASP.

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?


Literally every single person on this thread agrees: if you're going to rewrite code by hand, you wouldn't deploy something like Wasabi. Wasabi exists entirely to facilitate not rewriting.

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.


Wasabi is a case study in technical debt. This entire thread is a case study in I wasn't there, but I know more about it than the people who were.


And possibly of Greenspun's Tenth Rule. (Wasabi, not the thread.)


s/but/because


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

Agreed! But I would consider that an argument against using macros, not an argument for Wasabi.


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

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.


The piece you're missing is that Wasabi was a much smaller jump from where they started, which was VBScript. Sure, criticize Joel for using VBScript back in the 90s when he started writing a bug tracker at Juno, but in 2003, when Fog Creek decided to port to Unix, they had to make a decision based on where they were, not based on where they should have been.


One of my favourite programming books, is one I got on sale:

"Designing Active Server Pages - Scott Mitchell's Guide to Writing Reusable Code" http://shop.oreilly.com/product/9780596000448.do

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[1] 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) http://craigc.com/pg/

(Sometimes one finds great technical books on sale, too!)

[1] https://en.wikipedia.org/wiki/Fusebox_(programming)


Not criticizing, just trying to understand. I could be the one having to make the same decision tomorrow.


Ah, OK. BTW, I'm also just an outsider trying to understand and learn from the evolution of a mature product.


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

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


It makes more sense when you understand the "no rewrite" principal.

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.


Oh, it totally makes sense after the first steps. It's a clear progression - obvious, even. But if they had started with a better technology stack up front, it wouldn't have been (such?) an issue.


FogBugz was originally an internal tool meant to facilitate writing Fog Creek's original first product (CityDesk, a CMS). It seems pretty reasonable to go with whatever's most comfortable for an internal tool that you don't expect to sell, let alone to have different people running on different OSes.

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.


Spolsky has praised Lisp and Scheme and mentioned that it was used as the gatekeeper class at his university (e.g., http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool... ), which makes this comment funnier to me.


> The ASP->PHP conversion was extremely low-hanging fruit (the conversion involved almost no logic).

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.


PHP on Windows was comically bad at that time (~2000) - performance and bugs - which is especially bad for shared hosting environments. It wasn't until Microsoft's FastCGI for Windows 2003 and PHP 5.2 landed that we decided to roll it out on our shared platform. I speak from experience as an engineer/dev for a shared webhoster who was also on out of hours pager duty.


I agree. It also seems like they had a relatively straight forward migration path that worked out really well.

Sounds like good decisions were made at the right times.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: