Having now read it, I've come to the conclusion that the blog gives the wrong impression about the implications of having a custom language. Readers of the blog post come away with the idea that Wasabi was so full of "o.O" that someone was moved to write a book about that. In reality, the book is simply documentation of the language features, with callouts for weird interactions between VB-isms, ASP.NET-isms, and their language.
You should definitely read the "Brief And Highly Inaccurate History Of Wasabi" that leads the document off. It's actually very easy now to see how they ended up with Wasabi:
1. The ASP->PHP conversion was extremely low-hanging fruit (the conversion involved almost no logic).
2. Postprocessing ASP meant PHP always lagged, so they started generating ASP from the same processor.
3. Now that all their FogBugz code hits the preprocessor, it makes sense to add convenience functions to it.
4. Microsoft deprecates ASP. FogBugz needs to target ASP.NET. They can manually port, or upgrade the preprocessor to do that for them. They choose the latter option: now they have their own language.
It's step (3) where they irrevocably commit themselves to a new language. They want things like type inference and nicer loops and some of the kinds of things every Lisp programmer automatically reaches for macros to get. They have this preprocessor. So it's easy to add those things. Now they're not an ASP application anymore.
Quick rant: if this had been a Lisp project, and they'd accomplished this stuff by writing macros, we'd be talking this up as a case study for why Lisp is awesome. But instead because they started from unequivocally terrible languages and added the features with parsers and syntax trees and codegen, the whole project is heresy. Respectfully, I call bullshit.
If it had been a Lisp project, then Lisp programmers (and programming aficionados that have never used Lisp, but are attracted to its elegance) would be saying how awesome it is, and then most other developers would be talking about how they'd never work at Fog Creek because you have to use Lisp.
It's a good case study in market segmentation, though. Lisp works because all of the programmers who would like to do language design as part of their day job gravitate to it. As a result, it has the most advanced language features of any language on the planet. All of the programmers who just want their programming language to be a stable, dependable tool they can use gravitate to other languages (tops among them: Java and Go), and they build some pretty cool products with them because they aren't distracted by improving the language. Wasabi's big failing is that it tried to introduce Lisp-like concepts to programmers who have to work in ASP and PHP in their daily jobs. It's kind of a no-man's land there.
Respectfully, their example code is the following:
<%
<WebEntryPoint("example.asp")> _
Sub Example()
%>
<!DOCTYPE html>
<html>
<head>
<title>An Example Wasabi Program</title>
<meta charset="utf-8">
</head>
<body>
<h1>An Example Wasabi Program</h1>
<p>Arithmetic: 1 + 1 = <%= 1 + 1 %></p>
<p>Dynamic Content: x + y = <%= IntRequest("x") + IntRequest("y") %>
</body>
</html>
<%
End Sub
%>
I mean, they basically went to the trouble of building their own compiler to be able to keep writing Frankenstein ASP. If they'd built a language like Elixir I think people would be a lot more sympathetic.
> Quick rant: if this had been a Lisp project, and they'd accomplished this stuff by writing macros, we'd be talking this up as a case study for why Lisp is awesome.
Agreed! But I would consider that an argument against using macros, not an argument for Wasabi.
> Quick rant: if this had been a Lisp project, and they'd accomplished this stuff by writing macros, we'd be talking this up as a case study for why Lisp is awesome. But instead because they started from unequivocally terrible languages and added the features with parsers and syntax trees and codegen, the whole project is heresy. Respectfully, I call bullshit.
Interestingly, since new hires were supposed to be pretty smart and had to pay the cost of learning Wasabi anyway, they could have just taken a page from Paul Graham and gone with Lisp. The learning curve should be the same (or easier, given the amount of material available) and they would have crazy good compilers and libraries from day one.
I think we are missing a piece of the puzzle somewhere.
> Quick rant: if this had been a Lisp project, and they'd accomplished this stuff by writing macros, we'd be talking this up as a case study for why Lisp is awesome. But instead because they started from unequivocally terrible languages and added the features with parsers and syntax trees and codegen, the whole project is heresy. Respectfully, I call bullshit.
I was so sad, thinking about how using a cross-platform Lisp (I.e., LispWorks) would have solved this problem for them by design. FogCreek has some pretty smart folks, it should have been within their reach to use LW and go...
> The ASP->PHP conversion was extremely low-hanging fruit (the conversion involved almost no logic).
This is where I'm curious that they didn't just start writing PHP from that point forward. It was already a cross-platform language. And, if I recall, had a lot of hype and was gaining traction fast I'm the late 90's and early 2000's.
Certainly hindsight is 20-20, but I remember a lot of folks betting big on PHP at the time.
> 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.
>> 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.
"Embedding a programming language into a system has an almost erotic fascination to a programmer. It is one of the most creative acts that can be performed. It makes the system tremendously powerful. It allows you to exercise her most creative and Promethean skills. It makes the system into your friend.
The best text editors in the world all have embedded languages. This can be used to the extent that the intended audience can master the language. Of course, use of the language can be made optional, as it is in text editors, so that initiates can use it and no one else has to.
I and many other programmers have fallen into the trap of creating special purpose embedded languages. I fell into it twice. There already exist many languages designed specifically to be embedded languages. You should think twice before creating a new one."
> 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.
Nobody could know most things at the time. But we can estimate. What are the odds that small, random companies creating languages as side projects will have success? Well, looking at the languages everybody uses, I'd say: not so good.
> For example, Erlang started out being an internal tool at just one company, designed to solve a specific set of problems.
It was just one company, but it was one very large company working on something that they expected to be in operation for decades. So I think that's a bit different than a small company working on a product.
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).
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.
It's not necessarily true that it was an error. Their customers wanted Linux support, and they avoided the greater evil of having to rewrite their code or maintain two codebases (remember - this is ~2000 and there's no .Net or Mono, and all their code is written in old [edit:] VBScript).
I came away with a different impression to you: in the past there were good reasons to develop their own language; they recognised that those reasons no longer exist; they used modern tools to dig their way out from underneath the accumulated debt.
Nowadays we have open-source runtimes, .net running on multiple platforms, and componentised tools like Roslyn. It is easy to forget that the .net tooling from 10+ years ago was much more limited.
Writing you own language is an unusual approach, so descriptions of dealing with that kind of technical debt are rare. I thought this article was valuable and interesting.
> 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
I wouldn't worry about this at all. The choice of language on project n has never once negatively affected my work on project n + 1. As a programmer, my job has a lot more to do with solving problems (in the generic sense) than it does the tools I'm using to solve them.
Business software that provides business value is good software. FogCreek has been shipping Fogbugz to paying customers for fifteen years. If that's not success, it will do until success shows up. If that's a colossal error, where do I get one?
> 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).
I also found that passage oddly worded. We get it, people don't stick around forever, you don't have to try and hide it like it's some dirty little secret. Also as developer I doubt I would have wanted anything to do with a closed-source internal-only poorly-documented language. You may learn some concepts that transfer but by and large you will have to start from scratch when you leave and you won't have skills people are looking for. Also if you do dive headfirst into Wasabi and love it and then leave you probably will be that annoying fuck at your new company that says shit like "Well in Wasabi this was easy...." or "Wasabi makes this problem non-existant because...." Shut up, no one cares. It's crazy to me to think of a company as small as Fog Creek would attempt something like this but to be fair I was born and learned to develop in a different environment than they did so maybe the tools and languages available back then really just couldn't cut it.
Spending time working on Wasabi is only damaging to your career because of the current fad in hiring software developers that says "5+ years of Go development required."
I work with at least 10 languages a week. There is zero chance of us hiring people with years of experience in all those. We want people who have used multiple languages, and someone who worked on compiling one language into another would completely satisfy that itch.
> 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 (...) made such a colossal error as writing their own language
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
One of the best parts is that he pretty obviously has Spolsky dead to rights here, but typically DHH is thought of as an asshole and Spolsky as the software nice guy. But it's possible to spread FUD with nice-sounding words.
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
Those predictions were still off by ten years, however. Wasabi served them well until other technologies improved enough to allow them to ditch Wasabi.
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.
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.
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.
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.
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.)
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.
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.
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?
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.
> 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've been on that end and it really sucks, especially if you don't have the manpower to keep all platforms and versions in sync feature-wise. And there even was a C++ core that was identical across three platforms and yet there still was feature disparity and neglect.
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.
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.
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.
[+] [-] tptacek|10 years ago|reply
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.
[+] [-] nostrademons|10 years ago|reply
It's a good case study in market segmentation, though. Lisp works because all of the programmers who would like to do language design as part of their day job gravitate to it. As a result, it has the most advanced language features of any language on the planet. All of the programmers who just want their programming language to be a stable, dependable tool they can use gravitate to other languages (tops among them: Java and Go), and they build some pretty cool products with them because they aren't distracted by improving the language. Wasabi's big failing is that it tried to introduce Lisp-like concepts to programmers who have to work in ASP and PHP in their daily jobs. It's kind of a no-man's land there.
[+] [-] tedunangst|10 years ago|reply
[+] [-] themgt|10 years ago|reply
http://jacob.jkrall.net/wasabi-the-parts/a_first_program.htm...
[+] [-] serve_yay|10 years ago|reply
Agreed! But I would consider that an argument against using macros, not an argument for Wasabi.
[+] [-] outworlder|10 years ago|reply
Interestingly, since new hires were supposed to be pretty smart and had to pay the cost of learning Wasabi anyway, they could have just taken a page from Paul Graham and gone with Lisp. The learning curve should be the same (or easier, given the amount of material available) and they would have crazy good compilers and libraries from day one.
I think we are missing a piece of the puzzle somewhere.
[+] [-] pnathan|10 years ago|reply
I was so sad, thinking about how using a cross-platform Lisp (I.e., LispWorks) would have solved this problem for them by design. FogCreek has some pretty smart folks, it should have been within their reach to use LW and go...
[+] [-] tlianza|10 years ago|reply
This is where I'm curious that they didn't just start writing PHP from that point forward. It was already a cross-platform language. And, if I recall, had a lot of hype and was gaining traction fast I'm the late 90's and early 2000's.
Certainly hindsight is 20-20, but I remember a lot of folks betting big on PHP at the time.
[+] [-] TheMakeA|10 years ago|reply
Sounds like good decisions were made at the right times.
[+] [-] Udo|10 years ago|reply
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.
[+] [-] marktangotango|10 years ago|reply
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.
[+] [-] lenocinor|10 years ago|reply
The best text editors in the world all have embedded languages. This can be used to the extent that the intended audience can master the language. Of course, use of the language can be made optional, as it is in text editors, so that initiates can use it and no one else has to.
I and many other programmers have fallen into the trap of creating special purpose embedded languages. I fell into it twice. There already exist many languages designed specifically to be embedded languages. You should think twice before creating a new one."
from How To Be A Programmer ( http://samizdat.mines.edu/howto/HowToBeAProgrammer.html#id28... ).
[+] [-] wpietri|10 years ago|reply
Nobody could know most things at the time. But we can estimate. What are the odds that small, random companies creating languages as side projects will have success? Well, looking at the languages everybody uses, I'd say: not so good.
> For example, Erlang started out being an internal tool at just one company, designed to solve a specific set of problems.
It was just one company, but it was one very large company working on something that they expected to be in operation for decades. So I think that's a bit different than a small company working on a product.
[+] [-] krallja|10 years ago|reply
We had an interesting question: "why are we using two different languages to develop client and server side functionality?"
NodeJS obviously has the better answer, but much later than Wasabi.
[+] [-] zak_mc_kracken|10 years ago|reply
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).
[+] [-] tptacek|10 years ago|reply
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.
[+] [-] rwmj|10 years ago|reply
It's a great example of path dependency however.
BTW: Red Hat has been here too. We converted a huge app from .Net to Java by using some translation software: http://lpeer.blogspot.co.uk/2010/04/switching-from-c-to-java...
[+] [-] andyjohnson0|10 years ago|reply
Nowadays we have open-source runtimes, .net running on multiple platforms, and componentised tools like Roslyn. It is easy to forget that the .net tooling from 10+ years ago was much more limited.
Writing you own language is an unusual approach, so descriptions of dealing with that kind of technical debt are rare. I thought this article was valuable and interesting.
[+] [-] dionidium|10 years ago|reply
I wouldn't worry about this at all. The choice of language on project n has never once negatively affected my work on project n + 1. As a programmer, my job has a lot more to do with solving problems (in the generic sense) than it does the tools I'm using to solve them.
[+] [-] brudgers|10 years ago|reply
[+] [-] krallja|10 years ago|reply
[+] [-] joshstrange|10 years ago|reply
I also found that passage oddly worded. We get it, people don't stick around forever, you don't have to try and hide it like it's some dirty little secret. Also as developer I doubt I would have wanted anything to do with a closed-source internal-only poorly-documented language. You may learn some concepts that transfer but by and large you will have to start from scratch when you leave and you won't have skills people are looking for. Also if you do dive headfirst into Wasabi and love it and then leave you probably will be that annoying fuck at your new company that says shit like "Well in Wasabi this was easy...." or "Wasabi makes this problem non-existant because...." Shut up, no one cares. It's crazy to me to think of a company as small as Fog Creek would attempt something like this but to be fair I was born and learned to develop in a different environment than they did so maybe the tools and languages available back then really just couldn't cut it.
[+] [-] danielweber|10 years ago|reply
I work with at least 10 languages a week. There is zero chance of us hiring people with years of experience in all those. We want people who have used multiple languages, and someone who worked on compiling one language into another would completely satisfy that itch.
[+] [-] ExpiredLink|10 years ago|reply
Just like ... Rust.
[+] [-] w8rbt|10 years ago|reply
[+] [-] adnam|10 years ago|reply
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)
[+] [-] jameshart|10 years ago|reply
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
[+] [-] emodendroket|10 years ago|reply
[+] [-] serve_yay|10 years ago|reply
One of the best parts is that he pretty obviously has Spolsky dead to rights here, but typically DHH is thought of as an asshole and Spolsky as the software nice guy. But it's possible to spread FUD with nice-sounding words.
[+] [-] Marazan|10 years ago|reply
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
[+] [-] joshdick|10 years ago|reply
[+] [-] scotch_drinker|10 years ago|reply
[+] [-] scotch_drinker|10 years ago|reply
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.
[+] [-] jfb|10 years ago|reply
[+] [-] _pmf_|10 years ago|reply
[+] [-] brlewis|10 years ago|reply
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.
[+] [-] stevoski|10 years ago|reply
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.)
[+] [-] protomyth|10 years ago|reply
[+] [-] michaelbuckbee|10 years ago|reply
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.
[+] [-] mwcampbell|10 years ago|reply
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?
[+] [-] krallja|10 years ago|reply
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.
[+] [-] ygra|10 years ago|reply
I've been on that end and it really sucks, especially if you don't have the manpower to keep all platforms and versions in sync feature-wise. And there even was a C++ core that was identical across three platforms and yet there still was feature disparity and neglect.
[+] [-] chkuendig|10 years ago|reply
It's funny how they teamed up 2 years later to build stack overflow (and again used an MS stack)
[+] [-] tptacek|10 years ago|reply
[+] [-] cjensen|10 years ago|reply
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.
[+] [-] Locke1689|10 years ago|reply
[+] [-] overgard|10 years ago|reply
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.
[+] [-] noir_lord|10 years ago|reply
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.
[+] [-] pablosanta|10 years ago|reply
http://blog.codinghorror.com/has-joel-spolsky-jumped-the-sha...
Related blog post from a couple of years ago.
[+] [-] userbinator|10 years ago|reply
https://en.wikipedia.org/wiki/Inner-platform_effect