When Joel was cycling around the world (he has done that!), we were writting thousands of SLOCs. So don’t he come saying he’s an expert or something.
Ok…you DID read all of Joel’s post, right?
And you did read the earlier articles where he’d mentioned Wasabi, right? (this wasn’t, like, newly leaked material)
And you all DID catch the part where Joel explicitly said that wasabi “compiles down” into PHP and VBscript, right?
To me, that means he wrote a script parser…albiet a very intelligent one that fit a definate business need.
Not a whole programming language. Not something that compiles down to the bits-n-bytes level.
Jeff…I love your stuff, but man…lay off the wasabi. =^)) I don’t agree with everything Joel says either (the conspiracy theory on VMware almost made me laugh out loud) but I think that you may have jumped the shark on this one!
(ps. Umm…being an uncultured pac nwesterner…I haven’t a clue what “jumping the shark” means…)
Go in peace.
Jeff, I gotta tell ya. The joke’s on you.
It seems you (and everyone in the “I can’t believe he is making his own language” camp) haven’t realized so far that Wasabi is not a language in which FogBugz runs on.
It doesn’t matter if Wasabi-as-a-implementation-language sucks. If it is slow, or if only 3 people in the world know how to use it. What matter is the point that Wasabi is a tool to provide portability, generating code that can run on the “most deployed plataform out there”, whatever that is.
Funny thing is, I used to come to your blog from time to time. But this post made me realize that a) you are seriously lacking in reading comprehension and b)seeing your failing to understand the point of Wasabi, you may as well have a .NET/Java-poised mind, something that lowers you score somewhat with any respectful developer.
I think the phrase “jumped the shark” has jumped the shark.
Also, I notice nobody has answered Joel’s question:
"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?"
I imagine nobody has answered it because they can’t. I know I can’t. Why? Because most of us have never been in the position of “oh shit, I have a successful product and now people want to run it in environments we never intended it for. What do I do to capture those sales?”
That would be a great problem to have, really. Joel did what he figured would give him the biggest return on the labor. Does it seem a little goofy? Sure. But it appears to have been effective as hell.
Isn’t that what really matters?
Jeff, I gotta tell ya. The joke’s on you.
It seems you (and everyone in the “I can’t believe he is making his own language” camp) haven’t realized so far that Wasabi is not a language in which FogBugz runs on.
It doesn’t matter if Wasabi-as-a-implementation-language sucks. If it is slow, or if only 3 people in the world know how to use it. What matter is the point that Wasabi is a tool to provide portability, generating code that can run on the “most deployed plataform out there”, whatever that is.
Funny thing is, I used to come to your blog from time to time. But this post made me realize that a) you are seriously lacking in reading comprehension and b)seeing your failing to understand the point of Wasabi, you may as well have a .NET/Java-poised mind, something that lowers you score somewhat with any respectful developer.
Raphael on September 13, 2006 09:00 AM
Amen. Beyond that, since Wasabi = VBScript + Extensions (http://www.joelonsoftware.com/items/2006/09/01b.html), I’m sure there would be quite a few more than “3 people” who could pick it up. This brings up a few more points:
- If you will be doing code-generation, it seems quite logical to me to base it on a language that alot of people would know instead of coming up with a completely new langauge.
- Successful products tend to outlive frameworks, so porting/refactoring/upgrading/maintaining are real issues that, although distasteful to many developers, are crucial to making staying in business.
There’s a huge difference between making v.5 of an app with a hefty installed user base and making v.1 of 20 apps in the latest/greatest language/framework which will never see v.2.
If there is one thing I have learned over the years it is this: the best technology does not always win the market. In fact, most of the time it loses.
Let’s say I come up with some fantastic new product that is fully buzzword compliant and uses all the latest technologies. But my competition releases a similar product based on old technology but beats me to the market by three months because they used a bunch of (proven) legacy code to build it. Do you think the end user really cares if the back end is based on python, ruby, or C# .NET 2.0? No, they want to hit the button and have the product do what they paid it to do. And if it does it in 0.004 seconds instead of 0.002 seconds, they don’t notice/care.
The point is, Joel is in the software business. He’s not some abstract CS professor trying to find the most elegant and complete solution to a problem worthy of peer review, he is trying to give his paying customers what they want as fast as possible in order to make a profit. While everyone is pointing out technical flaws that have no effect on the end user experience, he’s raking in the cash.
It tickles me how people try to criticize something that they know nothing about. There are, maybe, 1000 words published about Wasabi.
How in the hell would you presume to understand the problems they faced? How would you presume to understand the solutions they debated?
It’s like someone in these comments saying that the real joke was that they had a report that needed millions of calculations, and how could this possibly be needed in a bug tracker.
Once again, an example of Uber-Ignorance. It’s the “I don’t understand this so I’m just going to say IT’S BAD!!!” Puh-leese.
Here’s a tip: Don’t run your mouth when you don’t know what you’re talking about. Frankly, I don’t think Joel got where he is today by making poor decisions. And I really doubt that they were sitting around one day and said “you know this vbs code is nice, but lets just reprogram it all in a brand new language that we can invent!”
What I love the most, is that Joel has talked for years about “Thistle” – a compiler to convert VBScript to PHP4. Everyone thought that this was just the cats pajamas. Thistle this and Thistle that.
Wasabi is essentially the same thing. The only difference is that instead of programming in VBScript, you’re programming in a VBScript-like language which includes features usually reserved for more powerful languages.
GET OVER YOURSELF.
It tickles me how people try to criticize something that they know nothing about. There are, maybe, 1000 words published about Wasabi.
Joel himself criticizes Wasabi-- and for many of the same reasons I do. Here’s a direct quote from Joel:
That said, there are major drawbacks [to Wasabi]. The documentation is a little bit thin and disorganized, because we’ve only documented the diffs to VBScript, not the whole language. Programmers that join Fog Creek might take a little bit longer getting up to speed. Our edit-compile-test loop got slower because there’s one more step.
Joel’s new favorite expression: CRICKEY! 
Deployment, deployment, deployment. Joel has his priorities right. Why do ISV’s struggle for oxygen while Web 2.0 companies breed like rabbits and get fed huge fricking carrots? Deployment.
Everyone has a web browser that is just good enough to do some interesting things that feel like interactive, seamless experiences. Thousands of engineers are writing code to use these web browsers despite the completely obtuse programming model and slow speeds.
This is because many users and corporations refuse or are too lazy to install software, and that practice is growing. If Joel wishes to remain an ISV his software must be nearly as easy to deploy as a web app. All other considerations are secondary.
Finally after reading a lot of hysterical posts, it seems that Wasabi is more or less a code generator.
What about the DRY (Don’t Repeat Yourself) principle, and the use of code generators, advocated by the Pragmatic Programmers?
In this case, does the benefit of DRY outweigh the burden of future FogCreek programmers learning and maintaining Wasabi? If so, maybe Wasabi’s fine.
OTOH, if Wasabi is just doing simple code generation to multiple targets, maybe standard scripting tools would suffice for that purpose.
I do find it interesting that the longest post I’ve ever seen on Coding Horror has to do with a company creating their own proprietary language; this seems to have drawn out the ire of a vast number of developers who are quick to say “that’s stupid; just use C# or Java or Ruby”.
Creating a proprietary language has a number of excellent attributes. I proposed just such an approach at a prior employer and we went through many discussions about it; the employer provided a software platform that was sold to our customers who then configured/customized it to run their own applications. This meant a great deal of development went into each project AFTER it left our development team. Competition was quite fierce in that market space and trimming customization and upgrade time for customers would have been a HUGE competitive advantage - competitors whose platforms customized quickly (unlike ours) and easily (unlike ours) got glowing reviews from the industry pundits like Ga^+n3r. At the opposite end, since we forced our customers to use C# or Java or C++ or VBScript to customize it meant that we had no control over the language and could provide no upgrade support if we changed underlying APIs, built a new server architecture or any number of other enhancements; had we used our own language we could change the meaning of the instructions - i.e., compile them to use the new APIs as opposed to the old ones. But with general purpose languages as the customization tools, the customer had to refactor all API accesses by hand. This put huge constraints on our ability to extend our product suite and/or modify APIs causing us huge RD expense. Additionally, since customers had to customize in a general purpose language rather than a domain specific language tailored to the programming tasks they would be facing, their development, maintenance and upgrade time/costs expanded. Customers had to use one language for server customizations and another for browser customizations, each of which had its own APIs. A proprietary language could be compiled to a language suitable for the server and to another language suitable for the browser enabling the customer to perform all customizations in the same language with the same business model abstractions. The business drivers for using our own language were tremendously enticing.
Of course, I’m sure the business people out there can guess why we never did create our own language and why we foisted a low level language off on the customers thereby (likely) tripling their customization time/cost and proably quintupling their upgrade time/cost. The reason we didn’t do this was a number of myopic senior developers who quailed at the idea because (and I paraphrase and insert some personal opinions of what they really meant inside square brackets) “a proprietary language will be so slow” or “it will be too hard [for us] to maintain” or “people [i.e., us] won’t want to use it because it is relatively unknown [and won’t look good on our resumes]” or “it will take too long [for us] to build applications with it” or my personal favourite “programmers like those who work for our customer [i.e., us] want to program in C# and work with MS DataSets; they [i.e., we] don’t want to use [i.e., have to worry about building] domain specific abstractions”.
I guess the point I’m trying to make is when developers attack somebody’s idea, such as Joel’s Wasabi, without knowing, let alone understanding, the business drivers that led to that decision, they only make themselves look like fools. I don’t know Joel from a hole in the ground, I don’t know his product and have no bias for or against him. I just find it a continual source of amusement (and irritation) when people lash out about things they know little to nothing about.
"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?"
Well, first of all, I’d note that PHP is a runtime not installed by default on UNIX webservers, particularly not if you’re talking about those in use in corporations, thus making 2 and 4 mutually exclusive.
When Joel puts this article into his next book, then you know for sure he has jumped the shark 
Brendan,
“Games were CPU limited and memory was scarce. Python may seem like it has a small footprint now, but it wasn’t that small back then…especially in games.”
Right, which led the ids and Epics to write their own custom solution. The context was games, and when I said that Python and other languages weren’t serious alternatives to writing your own thing from scratch, I meant it in that context. I know that Python is quite old and that many organizations other than game companies have used for a long time.
Code Complete by Steve McConnell suggests using code translators on page 499 (of the first edition), and says “…A translator is useful when you have a large code base that you’re moving to another environment.” This is the problem that Joel was looking to solve.
Furthermore, The Pragmatic Programmer by Hunt and Thomas include code generators as Tip #29, and Domain Specific Languages as #17, which both relate to Wasabi as well.
Jeff’s reaction must be based on a misunderstanding of the problem Joel was solving and how he solved it, because his own blog’s patron saint seems to think Joel’s approach is reasonable. If Wasabi is the next generation of “Thistle” then I think it’s consistent with what McConnell, Hunt and Thomas advocate.
We use FogBugz at our company and the fact that it didn’t need me to install and configure additional runtimes made my day much less stressful. Having tools that install painlessly is something I think is part of “The Programmer’s Bill of Rights”. If Joel can make a version of FogBugz that not only runs on Unix, but maintains feature parity with the Windows version, AND will use a runtime that probably already exists on the customer’s machine, then he’s giving me that Right.
McConnell’s recommendation of code translators goes on to say:
“The hazard in using a language translator is the same as the hazard in using a restructurer: If you start with bad code, the translator simply translates the bad code into an unfamiliar language.”
Wasabi, as I understand it, solves this problem because it was written to translate only one application–FogBugz–which was written with a Hungarian notation that made it easier to mechanically translate.
When I look at the VBScript source code of FogBugz, I can see lots of comments and clean and easily readable code. Whatever Wasabi is, its output is anything BUT an unfamiliar language.
What would I do? Well there’s no way to answer that without more information.
How many units of FogBugz are sold to Unix customers vs Windows customers. What percentage of his Windows customers absolutely refuse to install ASP.NET or other technology?
What is the productivity gain or loss in not having an integrated IDE for Wasabi? As far as we can tell from what Joel posted, Wasabi is the language they write code in.
I think “little languages” make a lot of sense, and to echo another poster, anyone who has ever looked at Smarty or another template engine and made their own instead is partly down that road already.
Think about it: you’re paying five developers to sit there banging on the keyboard all day. They could either be programming efficiently, writing one line of code that does the work of ten, or sticking doggedly to vanilla VB/PHP and using only basic constructs.
A good example of this is the way people normally talk to RDBMSs: three to five lines of initialization and setup code, three more lines iterating over the result set, etc., when a terse system like K/Kdb just treats database tables as built in objects and gives you a couple of short operators to iterate over and scan them.
If you have a few brilliant programmers at your disposal, why not smooth down some of the rough edges of your chosen language and let the computer emit and handle all the nasty details?
As for the Joel bashing, in the immortal words of Malibu’s Most Wanted, “Don’t be hating!”
Please separate the argument from the personal attack. Seriously.
I’m going to go out on a limb here and guess. My guess is that the sales to Unix customers is negligible when compared to Windows sales. I think eventually moving to ASP.NET as per Joel’s original plan still makes a lot of sense.
Unix customers who refuse to install Mono will find another solution. Can’t be all things to all people, right?
Benefits of ASP.NET
- Improved IDE over Wasabi’s IDE.
- Improved productivity.
- I can’t speak for FogBugz developers, but I wonder if they enjoy writing C# code over Wasabi. If so, then that would be a benefit.
- Easier to develop an extensibility model as Jon mentioned.
As Jon said, we use FogBugz at work and I’ve pushed to keep it over free solutions. From an end-user perspective, it’s great.
However, I don’t think they’ve built as enthusiastic a developer community around the product as they could. Build a simple extensibility model and watch the plugins roll in.
Look at Windows Live Writer which is totally Beta and buggy, but at the same time is inspiring tons of plugins. Wordpress is another example where there is a lot of enthusiasm for developers to build around a product.
Just my $0.02
I think Joel’s mistake with regards to his Ruby criticism is to lump dynamically typed languages together with them.
Python has show itself in recent tests that I have seen poking around the blog space to be quite a speedy contender. The fact that it coupled with Django power some pretty mighty newspaper sites appears to bear out it overall robustness for the problem space. Or am I wrong?
Joel’s use of his own programming language is sad. It reminds me of a small company called Ontario Systems in Muncie. Not a bad company, but it codes everything in a programming language called Mumps (http://en.wikipedia.org/wiki/MUMPS). While not its own language, it is quite rarified. Quite a few CS graduates from the local university, Ball State (http://www.cs.bsu.edu), go and work there for a while after school. More than one hated using Mumps because it didn’t help them build skills that were useful in many other places. In some ways, the felt it could result in career lock-in and they didn’t like that. Perhaps that’s another reason for using Wasabi.