Hacker News new | comments | show | ask | jobs | submit login
Has Joel Spolsky Jumped the Shark? (2006) (codinghorror.com)
70 points by shawndumas 1520 days ago | hide | past | web | 83 comments | favorite

Spolsky himself left a comment buried in the discussion on that article:

> Let's put it this way. You have these constraints:

> (1) Six years of code already written in VBScript

> (2) Needs to run on customers' Windows and Unix servers

> (3) Minimize tech support costs

> (4) Many customers refuse to install new runtimes on their servers, either because of IT policies or out of stubborness

> What would be your solution?

Anyway, whether it was a good solution or not, I don't quite understand the need that some people had to pick on someone so harshly. I never really followed Spolsky's blog but as far as I can tell it was pretty tame and respectful. Am I missing something?

Edit: Also, a compiler from one high level language to another is not the hardest thing in the world to write. We've got college kids these days writing new languages that compile to JavaScript. Maybe this was viewed as more of an extraordinary engineering feat back then or something.

Creating a new language is trivial (Hell, I've made one). Creating a robust, well-designed, full-featured, peformant language is very much not.

And that totally ignores the absolutely massive benefit of having a community around your language of choice. Libraries, bug fixes, googleability, a pool of programmers to hire from, etc, etc, etc.

I agree completely, but I am curious what your answer to his question would be. What would you have done in that situation?

I don't think the arguments against were hinged that much on difficulty. Mostly it stemmed from supportability, correctness, having to train all your new hires on your new language, etc.

Sometimes, sure, the right move is the least worst decision. But that doesn't excuse it for being a bad solution in general.

> I don't quite understand the need that some people had to pick on someone so harshly. I never really followed Spolsky's blog but as far as I can tell it was pretty tame and respectful. Am I missing something?

Fierce discussion isn't harsh, it's just that the underlying topic is so interesting that people feel inclined to pick apart the pros/cons extensively until they arrive a brick wall of pure disagreement.

Spolsky has been pumping out great, engaging content in his blog for years; I remember spending countless hours with my friends arguing over it. Then he wrote a couple of mediocre posts and stopped blogging altogether. Had it ended there, it would have been merely an astounding feat of self-awareness.

But it didn't end there. Joel had then converted his entire audience to seed Stack Overflow - the one invention that had the biggest impact on the programmer productivity in the 21st century. That's one hell of way to jump the shark, a gold-medal level performance. We would be lucky beyond measure if that sort of "disaster" happened to us every four years, or even each decade. But we're not so lucky.

Hats off to Joel Spolsky.

I hope you are aware Stackoverflow was actually created by Jeff Atwood. Joel just gave the initial idea something along the line like "let's make something like ExpertsExchange but less evil"

Not to mention, Stackoverflow was seeded initially by Atwood's audience (since he was the developer of the project to start with). I know because I was one of the first users back in private beta.

You're a bit misinformed.

Both Joel on Software and Coding Horror readers formed the initial audience.

While Jeff wrote code for StackOverflow, and Joel did not, Joel provided and acquired the initial funding to pay for Jeff's work, and hired the other talent required to allow the site to launch. It was neither entirely Jeff nor entirely Joel's creation, and I doubt it would've been able to launch without both putting quite a bit of backbone into it.

Ok. I still think its one of he best ways to jump the blogging shark - donate your audience to where it matters the most.

Joel didn't donate anything. Donations are given without return consideration which is hardly the case here since Stackoverflow was his business.

So does Spolsky get credit for SO or not? You can't have it both ways.

Here is Joel's article when SO launched: http://www.joelonsoftware.com/items/2008/09/15.html

I believe he also primed the pumps a couple of monthes in advance with Codinghorror, I was reading both at that time.

For reference: Jeff Atwood and Joel Spolsky founded Stackoverflow two years later.

[1] http://www.codinghorror.com/blog/2008/04/introducing-stackov...

Wow, ancient history, but this later became a standing joke, and Jeff mostly recanted. See http://pvm-professionalengineering.blogspot.com/2010/05/jump... (although why that site exists, I cannot say.)

From the comments on the article: "However, instead of upgrading to ASP.NET, they decided to.. write their own proprietary language that compiles down to VBScript/PHP/JavaScript."

Atwood then goes on to call it "crazy town."

Am I the only one who thinks that this decision might've paid off down the road for them? It sounds like he was just trying to code his app in a way that it would work in multiple types of server stacks, rather than trusting that MS wouldn't break their backwards compatibility again after doing so with ASP.net.

Maybe I'm wrong. I'm curious what the people who know way more than me think about this. I knew next to nothing about web apps in 2006, other than dabbling in PHP as a side note in a MySQL class.

By way of background -- at the time that we created Wasabi's predecessor, Thistle, we had a large code base in VBScript that only ran on Windows, and almost no developers. Thistle was done by a summer intern in eight weeks and got us PHP FogBugz running on Unix for 8 weeks work, which almost doubled our potential market.

At the time, Fog Creek consisted of three people and one summer intern. We couldn't afford to rewrite all of FogBugz in some other language... even if there was a language (in 2003) that was reasonably portable between Windows and Unix, which there wasn't. (Yes, we considered PHP. That would still have been a full rewrite, and PHP on Windows was crappy and increased the system requirements in a way that our customers wouldn't have liked).

Yeah, a Lexus is better than a Camry, but not everyone can afford Lexuses. So saying "you idiot, why are you driving that crappy car, it's obviously crappy" is not particularly insightful... the question is, if you can get 90% of the bang for 10% of the bucks, that's a pretty good decision as a startup, even if it seems strange.

What's more interesting about the reaction is that so many average programmers seem to think that writing a compiler is intrinsically "hard," or, as Jeff wrote in 2006, "Writing your own language is absolutely beyond the pale." To me this sounds like the typical cook at Olive Garden who cannot possibly believe that any chef in a restaurant could ever do something other than opening a bag from the freezer and dumping the contents into the deep fryer. Cooking? With ingredients? From scratch! Absolutely beyond the pale! Compilers aren't some strange magic black art that only godlike programmers are allowed to practice. They're something you learn how to create in one semester in college and you can knock out a simple one in a few weeks. Whatever you think about whether it's the right thing or not, if you think that a compiler is too hard to do as a part of your day job, you may want to invest some time in professional development and learning more about your craft.

To anyone reading this who still is in college, I can't emphasize this enough: TAKE THE COMPILERS COURSE. Yes, it's hard, but it's one of the closest things you'll get to programming superpowers compared to your peers.

I haven't written a compiler since I took the course... but I've written a lot of interpreters. And as the course will teach you, they are used everywhere, for a lot of things, even things you wouldn't expect. An HTML renderer, for instance, is basically an interpreter for the language called HTML, interpreting it into graphics commands. (Adding JS to the mix complicates things, but that's a decent understanding of a straight-up HTML renderer.)

Or if, like mine, your university didn't offer a compilers course while you were a student: Coursera has a compilers course offered by Stanford.

For something a little less formal, Jack Crenshaw's "Let's Build a Compiler" is a good introduction: http://compilers.iecc.com/crenshaw/

Compilers aren't black magic, but anyone who's never written one seems to think they are.

I think the neat thing I learned from my compilers class is that writing a compiler isn't insurmountable. The problem is, however, that writing a compiler for a full-featured language is quite an investment in time and thought.

Given that languages have developed quite significantly since 2006, if you had to make the same decision in this day, what would you do?


I learned more about the fundamentals of programming in one semester of compiler design than I did in the rest of 4 years of courses. It ought to be a requirement for any comp. sci. degre, IMO.

Well said. I like the cooking analogy. Part of the craft is enjoying what you do and pushing the limits, and you do that! Rails, Django, etc. may be practical, but using them takes some of the fun out of it.

It's interesting that in the linked post Atwood cites, as earlier evidence you may be jumping the shark, your (alleged) hatred of Java, a language designed to prevent programmers from hurting themselves by sucking. A lot of accepted wisdom in software engineering comes down to "you must use childproof safety caps because some of you are that stupid".

Java, of course, is so careful to protect global namespace that all kinds of "patterns" for disguising global state as something else emerged (woohoo "Singletons"), resulting in tools to find them and force them to be further disguised.

Another interesting thing (recall PG's aphorism that any sufficiently complex project contains a half-assed implementation of Lisp) is that designing ridiculously complex declarative syntaxes ("data") isn't considered beyond the pale on many projects (or at least it's allowed to happen through carelessness), but creating a properly defined language is.

"any sufficiently complex project contains a half-assed implementation of Lisp"

This actually predates PG - it's known as Greenspun's Tenth Rule[0]

[0] http://en.wikipedia.org/wiki/Greenspuns_tenth_rule

I think you and Jeff absolutely deserve each other, and are both equally fucking mental. (btw, stopped reading both of your blogs years ago specifically because of trite shit like this)

> We had a large code base in VBScript that only ran on Windows, and almost no developers.

So you roll your own language to improve things?

> Yes, we considered PHP.

I don't think you did.

> That would still have been a full rewrite, and PHP on Windows was crappy and increased the system requirements in a way that our customers wouldn't have liked.

Full rewrite into a cross platform language which only went on to improve and would have been far more backwards compatible [with a small eventual migration to php5]. I'm sorry but the fact you can't write a decent install script or manual to get your system working in different environments is not reason enough to roll your own language. Yes developing the compiler didn't take long but now you have a zero'd recruiting pool, a slower debug loop and an eventual fragmented maintenance nightmare. Oh and by the way, saying "PHP on Windows was crappy" is not particularly insightful...

> Cooking? With ingredients? From scratch! Absolutely beyond the pale!

It is when you're working at McD's though, and that is what Jeff everyone else was trying to tell you.

> What's more interesting about the reaction is that so many average programmers seem to think that writing a compiler is intrinsically "hard,"

We didn't react because we're average and think writing a compiler is hard, we reacted because you went against every common sense principal of software development there is. Any idiot who completes a degree can build a compiler / code generator, that doesn't mean its a good idea for your next web app. But go ahead, call us "average" delude yourself more, everyone who doubts you is just stupid because, well you're just such a godlike programmer.

I don't get it, its obvious, you're an MS flake, because of that you didn't want to use the logical choice, PHP, so you did something stupid. And now you can't just own it, instead you going around insulting everyone who calls you out. The best developers own their mistakes and learn from them, the bad ones flail around, blame the language, system, or other people.

Ive just downvoted you. Agree or disagree with Joel's decision - reasonable people do differ, but either way, your post was just plain rude.

Please dont write posts like that on HN.

Thats ok re the downvote, I know it was pretty on the nose. Post still stands though, kind of interested to see what Joel has to say.

I'm sory, but the only insulting post I see is yours.

I'm sorry, I thought I made that clear with the opening sentence.

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

Well "compiler" in this case is really "high-level code generator" instead of "low-level code generator". So yeah.

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.


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.

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.

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.

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.

> That's fair. But in my world “compiler” and “optimizing compiler” are very different things

Ah, ok. In that case, I'd agree.

Agreed. fortunately, there's LLVM for the back end now. And XL for the front end/AST

I'm not clear where people get this idea from. In the case of Wasabi specifically, it uses Code DOM, which can generate IL, C#, and VB.NET out-of-the-box, and can be extended fairly easily to target other platforms as well.

I have a theory about this. It has to do with the fact that Fogbugz started as off-the-shelf software, where companies would buy the CD and install the software on their own servers. The hosted version came much later.

Considering that most of the original code base was using ASP (there was no .NET when they started), this meant that all of their source code had to be shipped with the product. They couldn't just ship binaries. So part of me wonders if the Wasabi idea was a way for them to have obfuscation and some protection against piracy and competitor knock-offs.

I'm pretty sure it had more to do with supporting Windows and Linux server installs. I know we looked at FogBugz for an internal use, but at the time it was Windows only. Since we were a Linux shop, there was no way it was going to work.

I don't know... if Linux support was their only goal, there were other options that could be taken into consideration. I'm reasonably sure that around 2005 there were some solutions that made it possible to run ASP on Apache. At the time, even Mono/XSP was somewhat viable. [1]

[1]: http://www.codeproject.com/Articles/9738/Introduction-to-Mon...

Wasabi nowadays uses Mono, and until very recently, whether it was legitimately viable was a matter of opinion. Technically speaking, its garbage collector made it ill-suited to long-running processes (such as web servers), and its performance was far worse than the Microsoft CLR--frequently two to five times slower. Ideologically, we also met resistance; many Linux system administrators seem far more reticent to install Mono compared to PHP. Both have improved recently, but back in 2005, Mono was not a sane option.

Yeah, but I wouldn't have installed that on my server, it would have been too awkward and a support challenge for FogCreek. So, I think the idea was to support deployment on a standard runtime for each platform: PHP on Linux, ASP on Windows.

If customers prefer to run bug tracking software internally, then you are giving up a lot of customers by only offering external hosted solutions. If customers prefer one stack to another for internal solutions, then you are giving up a lot of customers by saying you only work on PHP or some other stack. If you just look at Joel's decision to write in something compiled to different stacks that can be run internally from a technical perspective, yeah, it sucks. But if it doubles the number of people who will buy your solution, then it may not suck from a business perspective.

Software is all about spending a fixed amount to produce it and then selling it over and over and over. If you double that fixed amount and double the over and over and over, you doubled your profits. Writing once and compiling to two things is less work than writing the same product in two different code bases as well. That sounds good and ignores things like buying a magazine ad becomes more efficient because more people who see the ad are potential customers.

As an engineer, I sure as hell wouldn't want to work on a system written in Wasabi. But as a business person, or an employee getting equity or options, it might make sense.

Does anyone know if FogBugz's codebase is still in Wasabi?

edit: Apparently it is, as of 2010. http://fogbugz.stackexchange.com/questions/210/is-fogbugz-7-.... Also, a 2011 Quora answer by Spolsky: "Much of the FogBugz code is still in Wasabi but a lot of it is in C# now." http://www.quora.com/Joel-Spolsky-Are-you-still-using-Wasabi...

FogBugz' core is still in Wasabi, but nearly all new code, including one hell of a release coming out soon, is in C#. The Wasabi core is gradually dwindling into an API shell, which will itself probably disappear at some point in the future. If you prefer to think of it this way: on any given FogBugz page load, you'll hit Wasabi, but the time spent in Wasabi will be increasingly tiny.

Kiln is pure C#/Python, Trello is pure CoffeeScript, and so on. Wasabi solved a porting issue. It wasn't designed for and isn't used for new stuff.

FogBugz in general is terrible. I use it everyday, and it's remarkable insofar as how amazingly bad the UI is. I was shocked to finally use software by Joel, who's essays I'd been reading for years, and discover that it was terrible.

I remember when I installed trial version of FogBugz many many years ago. Not to use it, but just to see what ideas I can take away from it.

I was shocked at how bad the software actually was in so many aspects. I was shocked because it was Joel who has been constantly talking about how to hire the best developers in NY so naturally my expectations were quite high.

Reflecting back on all of this, I'm sure the software probably wasn't bad, it's just that through Joel's amazing writing he has created very unreasonable expectations.

The lesson I've learned from it was to lower expectations of my users before they use my software, and then exceed them.

Well, Trello is awesome. I don't think anyone can dispute that.

The pricing model is also something from another era. It's an incredibly unattractive option for small teams just starting out, especially when compared to all the reasonably priced high quality options out there (github etc.)

I mostly agree. The most interesting thing about it is the Evidence Base Scheduling idea [1] but I have no idea if that actually works in practise. I would like to see more project management and tracking tools implement something like this.

[1] http://en.wikipedia.org/wiki/Evidence-based_Scheduling

"I was shocked to finally use software by Joel, who's essays I'd been reading for years, and discover that it was terrible."

Spolsky's writings have always seemed to me to be completely vapid and obvious, at best.

To see what a great reputation he has among pointy-headed bosses and developers alike is a sad comment on the state of the industry.

That his company writes crappy software should surprise no one.

Well, I guess I'm just an idiot and a fool. You must be great to work with.

I'm surprised that you're surprised that your incredibly negative comment yielded an incredibly negative response.

I think people just get used to Jira's special brand of awful and find it hard to move to anything else.

One of the worst non-free tools I've ever had to work with. Have been extremely skeptical/critical of anything I read of his after dealing with fogbugz.

Edit: toned it down.

I was excited a few years back to finally get FogBugz set up for my new company to use on a project, only to find it incredibly frustrating to use, and dropped it like a stone.

The lesson I learned is that people who write a lot of interesting things about software development (I've read almost everything on Spolsky's site) don't necessarily create good software themselves.

I use it every day, and I think it's great (including the UI). I'm curious to see what, specifically, you find terrible about it, and which bug tracking system you find to be better.

I think the main reason people bash the UI is because it doesn't look shiny. I think the reason people don't like the rest of it is because it forces you to use it a certain way and people don't spend the time to actually learn or get used to it. It's not perfect (speed wise), but if you give into how it wants you to use it, it works well.

Here is some detail on the kind of stuff Wasabi does:

"[H]ow to translate [this bit of VBScript] a(1), which could mean "look up the 2nd element of array a" or "call the default method of the object a passing the argument 1" depending on what type a contains at runtime? This really matters, because we use arrays, and because we use the built-in class RecordSet all over the place, doing things like rs(1) which is short for rs.Item(1).Value, and since VBScript is latebound there is no way to know what code to generate in PHP until runtime, and that's too late! The only correct thing to do in PHP would be to generate code that checks the type of a, and decides, at runtime, whether to do an array lookup or a method call. This is messy and slow and would suck big rocks in the kinds of tight loops where you tend to be using arrays.

How did we fix it? Well, thanks to Hungarian notation, so callously dissed by developers who do would not recognize a superb coding convention if it walked up to them on the Shanghai Maglev train and shook their pants leg, every recordset at Fog Creek starts with the letters "rs". And Thistle looks for the rs and say, "ah, this is a recordset, you're not looking for an array value, you're calling the default method," and generates fast code. Based on your age you will either call this an evil hack (if you're young) or an elegant hack (if you're old); in either case it's a huge optimization made possible by the fact that Thistle only has one program to compile. Outside of Fog Creek it wouldn't work. All hail Hungarian notation!"


I like how making it so that variable names determine whether or not the compiler generates correct code is labeled an "elegant hack". To borrow his phrasing, this makes me wonder if Joel would recognize an elegant hack if it walked up to him on the Shanghai Maglev and shook his pants leg.

I would barely call this a hack at all; it's only a hack under the view that it feels icky to evolve a programming convention into a language construct. Languages have been treating (parts of) variable names as part of the type system for ages: Fortran, BASIC, Perl, ...

What could possibly go wrong

I wonder if any of his intern developers switched career after working there :|

I feel dirty after reading that... oO;

Reading the entirety of Spolsky's post was especially interesting for me to to read:


Interesting to see Joel's comments on web stacks built with Python and Ruby back in 2006, and even taking a snipe at Lisp. I really can't decide whether web development has fundamentally advanced in every way in the past 5-8 years, or whether it's essentially the same.

Keep in mind Ruby on Rails had been out for less than a year at the time I wrote that, and the only thing I said about it was that brand new frameworks are not the kind of thing that enterprises like to bet the farm on.

As opposed to things like, say, brand new languages that compile down to VBScript.

The whole Wasabi story sounds eerily similar to this classic Daily WTF: http://thedailywtf.com/Articles/Classic-WTF-We-Use-BobX.aspx

A good reason not to do anything interesting with programming languages in your company: because if word gets out that you did, you'll never, ever hear the end of the snarky comments about it.

well said. i was actually quite impressed that they were willing to pay the up-front cost for developer productivity by writing a targeted dsl for their app.

I don't think you get it: enterprises don't want to put new runtimes, platforms, etc on their hardware, EVER. As far as the enterprise IT dude is concerned, the VBScript is VBScript. He doesn't know or care how it was created, as long as it runs on the Windows box the 2006 corporation demanded he use. It seems to me that Joel was just trying to code once, and have the app run for customers who were tied to Windows only (and PHP ran like shit on Windows back then). Keep in mind how difficult it can be to deploy software in a large enterprise. It's never technical difficulty, its bureaucratic. Go to ACME Widgets, Inc., try to install Ruby on a server, and see how many weeks/months of hell you have to go through to stand it up.

When I was working for a large enterprise the only way to get around it was to work on an illegal server someone had built. They had it sitting under their desk and only let a few people have access to the box to ensure that word didn't get out that a 'rogue' box had been set up on the network.

As long as you either control the whole stack, or the stack is built on top of components that are considered mature, there is not much of a problem there.

Joel doesn't run an Enterprise company. So that advice doesn't apply to him. There's nothing difficult about this to understand.

Was Wasabi a deliberate attempt at a new language, or did it organically grow out of your ASP to PHP compiler? You used a subset of ASP (and enforced stuff like Hungarian notation) - was the Wasabi language 1.0 just "Wasabi is the subset of ASP that compiles into PHP using Thistle, so stop submitting bugs on unsupported features" kind of thing? And from there, it's a small step to adding syntactic sugar (then it's "a superset of a subset of ASP").

In the beginning, there was Thistle. Thistle was, at best, a glorified regex that converted ASP to PHP. It was written by an intern, and it showed.

Later, Thistle was broadened out into an ASP to PHP compiler. Compiler was still a loose term; there was still a lot of regex magic that relied on you following Hungarian apps notation. That said, I'm fairly confident that this version of Thistle did build an AST for code generation, which does mean it qualified as a real compiler.

That matters because this version of Thistle was extended out with two additional features: it could compile VBScript to JavaScript, and it added some conveniences to VBScript, such as macros (called picture functions (don't ask)), lambdas, and simplifications to the declaration system. Don't laugh too much at the former; the motivation was the same as for RJS or Seaside's JavaScript support. All three technologies are dead now, and for good reason, but it was modish at the time.

Later, when .NET came out, and VBScript was end-of-lifed, that left us with the option of rewriting the whole thing...or making a "real" compiler that could compile VBScript to .NET. Wasabi was born. Wasabi was written as a proper compiler that could translate VBScript to C# and (for legacy reasons; see above) JavaScript. Wasabi, unlike Thistle, was a real, full-blown compiler, in a CS sense, so it was feasible to add type inference, lambda expressions, and several other niceties, without spending too much effort. That said, the goal here was to allow transition: new components, with restrictions, could be written in C#. The idea was that, at least hopefully, Wasabi would gradually be deprecated.

So no. It was never meant to be a new language. It was always intended to be a stepping stone, a translator between languages, not a real language in itself. While it gained some additional features, that was to make working in the damn thing palatable--not to be a real language in its own right. Emitting C# and .NET IL are actually about equally easy if you have a real compiler, but Wasabi always emitted C#, specifically so that we could one day ditch the whole thing.

What's the status today? Have you ditched it?

>ASP to PHP compiler


Here's more of the back-story to why they created the ASP->PHP compiler in the first place: http://www.joelonsoftware.com/articles/FogBugzIII.html

And he was so convinced that Joel had jumped the shark that he went into business with him.

At Taodyne, we also developed our own language. That lets us do that: http://www.youtube.com/watch?v=9vv18SFljzA. No other language fits the bill.

Try that in Javascript or PHP and see if you can fit the whole thing in 15 minutes (the YouTube upload limit)

Sometimes designing your own language is just the right thing to do.

Having read the linked post by Jeff, the post first mentioning Wasabi by Joel, and the follow up to it, I'm not sure I can see what all the fuss is about?

There are a few things that I think sound wrong, things like performance comparisons with Ruby, although I wasn't doing web development in 2006, and I'm sure it was a very different time.

However I don't think Jeff was entirely fair to Wasabi. He picked on it compiling to VBScript, but I think Joel explained clearly that it was only one of the possibilities, and in fact PHP5 would have been a perfectly good target to compile to.

I think we have a lot more choice now for web applications, and therefore I don't think it's justified to write your own compiler and language in-house anymore for something like this. However at the time, I think what Fog Creek did with Wasabi was a good decision, and actually quite inspiring.

i'm asking in advance for a little indulgence as I trot out my language snobbery:

I had to check that the blogpost wasn't an April 1st submission because the entire premise of writing a toolchain to get cross-platform compatibility out of Visual Basic has get to be April Fool's material. The fact that the language is interpreted from VB into other languages that might generously be described as "partially good" (like JavaScript and PHP) just takes this whole thing over the top.

in other words my mind is blow (as per Atwood's comment) that the goal of cross-platform compatibility wasn't achieved in a sane way, like just using Java or Python.

Gold. Thank-you for posting this. I missed this.

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