Killing Off Wasabi - <AUTHOR> http://blog.fogcreek.com/killing-off-wasabi-part-1/ <comment><USER2> 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.

<comment><USER3> 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)

<comment><USER4> 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)

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

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

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

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

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> _> 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.

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

<comment><USER9> 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)

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

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

</comment></comment></comment></comment></comment><comment><USER12> 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).

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

<comment><USER13> 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) )

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

<comment><USER13> "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.

<comment><USER14> 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)

</comment></comment></comment></comment></comment></comment><comment><USER15> 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)

<comment><USER16> 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

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

</comment></comment></comment><comment><USER18> 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

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

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

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

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

</comment></comment></comment></comment></comment><comment><USER19> 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.

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

</comment></comment><comment><USER22> 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.

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

<comment><USER24> 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 "??????????????")

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

<comment><USER24> 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?

<comment><USER26> 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))

</comment></comment></comment></comment></comment></comment><comment><USER27> _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.

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

</comment></comment><comment><USER29> 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.)

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

</comment></comment><comment><USER31> 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.

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

</comment></comment><comment><USER33> 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.

</comment><comment><USER25> 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?

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

<comment><USER25> 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.)

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

</comment></comment></comment></comment><comment><USER35> 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)

</comment><comment><USER2> I'd really, really like to read _Wasabi – The ??? parts_.

<comment><USER34> Wasabi: The ??? Parts

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

<comment><USER2> 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. :)

</comment></comment></comment><comment><USER36> 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.

<comment><USER34> 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).

</comment></comment><comment><USER37> Super excited to see what you did with Roslyn! We'd love feedback on things we could do to improve the experience!

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

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

</comment></comment></comment><comment><USER38> 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.

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

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

</comment></comment></comment><comment><USER39> 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.

<comment><USER21> They got almost 10 years out of it. Even with accumulating technical debt, that reads like a success to me.

</comment></comment><comment><USER40> 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.

<comment><USER41> This is the first thing that came to my mind too.

</comment></comment><comment><USER42> 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)

</comment><comment><USER43> _" 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)

</comment><comment><USER44> 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.

</comment><comment><USER45> A company should never build a compiler, database, or operating system if it is not their primary business.

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

<comment><USER47> 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?

</comment></comment></comment><comment><USER48> 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.

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

</comment></comment><comment><USER50> _Building an in-house compiler rarely makes sense._

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

</comment><comment><USER24> I guess this worked for them, for some value of the word "worked", but it always seemed like a bad idea to me.

</comment><comment><USER51> Isn't this exactly what everybody said when they announced Wasabi in the first place?

</comment><comment><USER52> 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?

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

<comment><USER52> 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

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

</comment></comment></comment></comment><comment><USER55> 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.

</comment><comment><USER56> 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.

<comment><USER57> 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.)

<comment><USER56> 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.</comment></comment></comment>


Tempe Police release fatal Uber crash video - <AUTHOR> https://www.bizjournals.com/phoenix/news/2018/03/21/tempe-police-release-fatal-uber-crash-video.html <comment><USER2> Looks like the human in the car was at fault? If he was watching the road she would have survived, and that's exactly what he was paid to do.

</comment><comment><USER3> Frankly, I'm not sure I would have done any better.</comment>


Vinnie – Your Wine Assistant - <AUTHOR> https://vinnie.app <comment><AUTHOR> Don't know which wine to choose for dinner? Vinnie is the app that helps you choose the best wine for every occasion. Based on users' feedback and on artificial intelligence to help you find out your food pairing, Vinnie selects the perfect fit for your needs.

Check this out and don't hesitate to get back to us for some feedback !</comment>


Ask HN: Best Fiction Hacker Books? - <AUTHOR> What are some of the best hacker\tech geek books, people have read?<p>The Blue Nowhere is one of my all time favorites! <comment><USER2> [https://www.teamten.com/lawrence/writings/coding- machines/](https://www.teamten.com/lawrence/writings/coding-machines/)

This is not a book but it is the best fiction featuring programmers I have ever seen.

Edit: Looks like it is also available as an ebook.

<comment><AUTHOR> Looks like an awesome read!

</comment></comment><comment><USER3> Zero day by mark russinovich (yes, the CTO of Azure)

The first few chapters of Zero Day focus on a series of devastating attacks by a new breed of malware that is causing pilots to lose control of their aircraft, making hospital record systems fail, disrupting robotic auto assembly lines, and causing nuclear power plants to fail. That's when protagonist Jeff Aiken enters the scene. Something of a lone wolf computer security genius

</comment><comment><USER4> An oldie but a goodie - The Adolescence of P-1, Thomas Ryan</comment>


Intel buys Rivet Networks and its Killer Networking brand - <AUTHOR> https://www.pcworld.com/article/3543884/intel-buys-rivet-networks-and-its-killer-networking-brand-to-beef-up-its-wi-fi-tech.html <comment><USER2> What is the point of this acquisition? The article says it's to "beef up Intel's Wi-Fi tech." But Killer's recent Wi-Fi adapters were essentially rebadged Intel hardware already:

Killer AC1550 = Intel AC9260

Killer AX1650 = Intel AX200

Did they do anything else besides tweaking the driver a bit and reskinning it with a repugnant UI? (Click at your own peril: [https://images.anandtech.com/doci/12178/ces_deck_2018_pre_br...](https://images.anandtech.com/doci/12178/ces_deck_2018_pre_briefing_final- page-007.jpg) )

I guess it's mostly about getting the "Killer" brand, which can be used for future Intel products?

</comment><comment><AUTHOR> Original title was too long. It was:

Updated: Intel buys Rivet Networks and its Killer Networking brand to beef up its Wi-Fi tech</comment>


Show HN: How to Say Anything in Japanese - <AUTHOR> https://learn-japanese.org/2020/03/04/introducing-how-to-say/ <comment><USER2> With an exception of "hello" I invariably got "Human being has been summoned to deal with your query" with some gif of dogs running across the room. For the "hello" it showed "konichiwa", but didn't actually pronounce it. Clicking on "How does it work" yielded yet another attempt of the site at looking up this exact phrase rather than explaining how it works. There were also layout issues with the page content - some text was overlapping the entry field or some such.

Perhaps I'm missing something obvious, but I see no point or utility in this site.

<comment><AUTHOR> Thanks for your comment, we added a "Latest Additions" that shows the newest entries that have been added. Yes, if you click "How does this work" and then commence the query, the result page actually says that a human being language expert will craft a query result for your search term. Would you want to be notified when the result is ready? We were trying to evaluate how important this feature is.</comment></comment>


AutoIt - <AUTHOR> https://www.autoitscript.com/site/autoit/ <comment><USER2> AutoIt is pretty powerful and good for learning basics of programming. I last used it a decade ago and it was surprisingly powerful.</comment>


Sentient aliens are probably terrestrial - <AUTHOR> https://keplerlounge.com/2016/08/19/sentient-aliens-are-probably-terrestrial/ <comment><USER2> Dolphins are sentient. Don't take my word for it tho: [http://www.livescience.com/39481-time-to-declare-animal- sent...](http://www.livescience.com/39481-time-to-declare-animal- sentience.html)

</comment><comment><AUTHOR> I think there's a strong upper-bound on the collective intelligence of any strictly aquatic species.</comment>


Social Media playing a big role in Vancouver Riot Aftermath - <AUTHOR> http://thenextweb.com/ca/2011/06/16/twitter-playing-big-role-in-reporting-of-vancouver-riot/http://thenextweb.com/ca/2011/06/16/twitter-playing-big-role-in-reporting-of-vancouver-riot/
 The article itself is mostly about twitter--and to be fair it's not necessarily a life shattering article, but I think it's culturally relevant, especially given what has developed in my country. I wanted to point out that for as much problems social media has played in this issue (it's being reported that Facebook riot groups were set up prior to Game 7) the great things being done using these same devices are of redeeming quality and shows that it isn't so much about the tool--but how you use it, and it's good to see so many Vancouverites putting social media to good use to help restore the city after it's shameful evening. <comment><AUTHOR> Hey guys this was my first submission on HN, but I wanted to add this-- The article itself is mostly about twitter--and to be fair it's not necessarily a life shattering article, but I think it's culturally relevant, especially given what has developed in my country. I wanted to point out that for as much problems social media has played in this issue (it's being reported that Facebook riot groups were set up prior to Game 7) the great things being done using these same devices are of redeeming quality and shows that it isn't so much about the tool--but how you use it, and it's good to see so many Vancouverites putting social media to good use to help restore the city after it's shameful evening.

Hopefully someone else will find this interesting.</comment>


How to accept Bitcoin payments without running a full node - <AUTHOR> http://incoherency.co.uk/blog/stories/how-to-accept-bitcoin-payments.html <comment><USER4> If you're going to run a payment system this way, by generating addresses and then checking if they've confirmed, the better way to do it (rather than pre- generating a batch), is to use hierarchical deterministic (HD) wallets. This way, instead of having to re-generate a batch of one-time receiving addresses to use on a regular basis, you generate a master key and then use the algorithm to generate addresses without having to use a full Bitcoin node (there are libraries in Python, JS, and all the common languages, look for "BIP 32" or "HD Wallet"). All you need to generate the deterministic addresses on your server is the master public key, thus there's less security risk (if the master public key is disclosed, it threatens the privacy of your users, but not the integrity of your funds).

If you don't want to bother generating the deterministic keys online, you could pre-generate thousands, even millions of them if you want. And keep both the private and public master keys offline. It also is a safer approach since you can securely store the master private key in a offline hardware wallet and not have to worry about keeping track of hundreds of private keys.

Long time since I've been active in Bitcoin, but this is the way I would have run a payment service without using a full node.

</comment><comment><USER5> Author here, surprised to see this on HN! I considered submitting it myself but didn't think this crowd was that into Bitcoin. Nice to be proven wrong :)

A couple of people mentioned HD wallets:

I initially tried using an HD wallet, but the mechanism for interacting with it was more inconvenient than generating keys manually - <USER3> considering that you might have to generate hundreds of addresses in a row that never receive a payment.

I've added an update at the end of the article.

Cheers!

<comment><USER4> > I initially tried using an HD wallet, but the mechanism for interacting with > it was more inconvenient than generating keys manually - <USER3> > considering that you might have to generate hundreds of addresses in a row > that never receive a payment.

Not sure I follow. The only difference between generating a HD-derived address and a traditional address should be that the former can be re-generated based on the master key alone. Not sure what difference not receiving payment at hundreds of addresses would make between the two.

<comment><USER5> I agree. Using an HD wallet would work fine. I found the tooling less convenient so I didn't use an HD wallet.

</comment></comment></comment><comment><USER6> 21 Inc. (where I work) has a very easy to use python library [1] allowing you to accept bitcoin payments via HTTP 402. But you can also just use the library to serve up a fresh payout address in plaintext on a website.

If you like the CLI, it has that too; it's a fully-compliant HD wallet. Getting set up is as simple as it can be

        $ curl https://21.co > setup.sh
        $ sh setup.sh
        $ wallet create
        [write down mnemonic]
        $ wallet payoutaddress
        [printed payout address]

Then you can use `wallet history` or `wallet balance` to see incoming payments, and `wallet send` to send money to a recipient.

If you like the advanced stuff, it has support for micropayment channels, too.

[1] [https://github.com/21dotco/two1-python/](https://github.com/21dotco/two1-python/)

</comment><comment><USER7> > Third-party Bitcoin payments services typically take a 1% fee.

This is not accurate. Bitpay (most popular payment provider) charges you only if you settle (convert your BTC to USD).

If you are going through an exchange (bitfinex for example), you'll pay 0.2% for taker rates.

0.8% seems reasonable enough for me considering that Bitpay provides a decent interface and decent tools.

<comment><USER8> +1. That ~1% fee is for merchants who want to accept btc but don't want to deal with the ecosystem. They just provide their bank info to the processor and get fiat deposited there.

</comment></comment><comment><USER9> This is reckless. If your hardware corrupts data too often to sync a full node, the solution is not to hack together a homemade payment processing system with only SPV-level security that will run on your faulty hardware. This approach and the attitude behind it will lead to losing money and losing track of customer payments, probably sooner rather than later. Rolling your own payment processor is a great way to learn more about bitcoin, but use testnet coins. If receiving real money is what you want, use a tested library written by someone who put in the time and experience to do it the right way, or use a 3rd party payment processor. Don't learn with real money; that's learning the hard way.

</comment><comment><USER10> The author mentions being plagued by crashes/corruption, but I've never experienced this and I've been running a full node for a few years. Other than the large (well, not _that_ large) storage requirements (.bitcoin is currently 101G) I've not got any complaints...

Unless there's a bug in a recent version of bitcoind which causes it to crap out when initially catching up with the network?

<comment><USER5> I've been informed that crashes+corruption indicate either lack of memory or hardware faults. Bitcoin needs to do an awful lot of cryptography, and it all needs to come out perfectly for it to work, so it tends to be sensitive to hardware faults.

<comment><USER11> If you're doing bitcoin crypto on a machine without ECC RAM, you're a madman.

</comment></comment></comment><comment><USER12> > _I use the keyconv program from vanitygen as a convenient way to do this. > Simply running "keyconv -G" generates an address and private key and outputs > them._

You have to really trust that vanitygen tool. If there's some bug where there's not enough entropy in the private key generation, ALL your temporary wallets become vulnerable (e.g. someone can generate your private keys).

<comment><USER5> The keyconv program is extremely short, it simply calls the key generation routines in OpenSSL.

</comment></comment><comment><USER13> I'm the original author of "Straight", a stand-alone opensource Bitcoin payment gateway - a software that allows you to accept Bitcoin payments: [https://github.com/MyceliumGear/straight- server](https://github.com/MyceliumGear/straight-server)

It is now part of the Mycelium Gear project, which is a hosted commercial version of it, and I don't work for the company anymore, but the team behind it that I hired and worked with is really great and they keep working on the product.

</comment><comment><USER14> A problem I'm currently addressing that maybe someone can help with:

I'm using a BIP32 HD wallet master pubkey to generate addresses on the payment front-end. Now, the ideal payment-watching solution would be the following; it maintains a set of "active" addresses, which I can add to whenever, and notifies me whenever one receives a confirmed payment. However, I'm not sure if this exists. I would also settle for me being able to query arbitrary address balances quickly.

Bitcoin-core doesn't work because adding an address causes a rescan of the entire blockchain (as it doesn't maintain an address-indexed UTXO dictionary for all addresses), which is too slow. I think electrum-server might work. Even though I'm following the same derivation path as electrum-client, I don't think I can use electrum-client for this (because I could conceivably be attacked with hundreds of thousands of address generation requests, which I doubt electrum-client will like). I also want to ignore adderesses more than, say, a week old, which I don't think electrum-client supports.

</comment><comment><USER15> Article recommends creating private/public pair via vanitiygen but imo that's not the best way to do it.

Alternative:

Create HD wallet (via electrum e.g.), get "public master key" and use it everywhere. You can generate consequent public addresses using that key but you can't generate private keys (i.e. spend anything). Now your server is protected from stealing any money and don't require any special backups for these new keys.

</comment><comment><USER16> Hi jstanley great article I'm running similar system at [https://inthebitcoin.com](https://inthebitcoin.com) for few months and it works great for me. No need for any third-party payment system. Space (101GB) is cheap this days !

</comment><comment><USER17> Seems [http://www.nem.io](http://www.nem.io) have built their software separating in client and server components, the client using the rest api published by the server. Would that be a good approach?

</comment><comment><USER18> Just use Electrum, bread wallet for iOS or one of the many other spv clients. No need to run a full node, haven't needed to for years.

</comment><comment><USER19> Doesn't stripe support bitcoin?

</comment><comment><USER18> Just use Electrum, bread wallet for iOS or one of the many other spv clients. No need to run a full node, haven't needed to for years.</comment>