5 ms·

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

by Udo 11y ago

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

marktangotango 11y ago
>> 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.
- Udo 11y ago
  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)
  - marktangotango 11y ago
    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.
    - relaytheurgency 11y ago
      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.
  - D-Coder 11y ago
krallja 11y ago
> Wasabi might have become a noteworthy language outside Fog Creek 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.
- gclaramunt 11y ago
  yeah, and the answer is "No"
- MichaelGG 11y ago
  Not really a better answer. It'd be better to take a well-designed, "top" language, and output JS or WAS from that.
wpietri 11y ago
> 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.
- tedunangst 11y ago
  rails? php?
- chc 11y ago
  Didn't Python, Ruby, JavaScript, CoffeeScript, Perl and PHP all start as essentially side projects or hobbies?
  - wpietri 11y ago
    Hobbies are very different than company projects like this. With hobbies, we don't really care about ROI; we do it for the fun of it. In companies, ROI is very important. And naming the successes doesn't tell you much about the odds; you also have to count the failures. One can't justify the purchase of a lottery ticket by looking only at the winners.
    - reagency 11y ago
      Read up on the origins of JS. You will be surprised. It was a rush hack job to.save a company from an existential threat. Like wasabi
      - wpietri 11y ago
        Sure, but that strikes me as the exception that proves the rule. JS succeeded not because of language merits, but because it had strong distribution. JS was basically held in contempt for a decade until the platforms and the language matured enough to make it useful for something more than button rollovers and form validation.
lenocinor 11y ago
"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." from How To Be A Programmer ( http://samizdat.mines.edu/howto/HowToBeAProgrammer.html#id2854864 http://samizdat.mines.edu/howto/HowToBeAProgrammer.html#id28... ).

by Udo 11y ago

marktangotango 11y ago

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

Udo 11y ago
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)
- marktangotango 11y ago
  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.
  - relaytheurgency 11y ago
    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.
- D-Coder 11y ago

krallja 11y ago

> Wasabi might have become a noteworthy language outside Fog Creek 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.

gclaramunt 11y ago
yeah, and the answer is "No"
MichaelGG 11y ago
Not really a better answer. It'd be better to take a well-designed, "top" language, and output JS or WAS from that.

wpietri 11y ago

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

tedunangst 11y ago
rails? php?
chc 11y ago
Didn't Python, Ruby, JavaScript, CoffeeScript, Perl and PHP all start as essentially side projects or hobbies?
- wpietri 11y ago
  Hobbies are very different than company projects like this. With hobbies, we don't really care about ROI; we do it for the fun of it. In companies, ROI is very important. And naming the successes doesn't tell you much about the odds; you also have to count the failures. One can't justify the purchase of a lottery ticket by looking only at the winners.
  - reagency 11y ago
    Read up on the origins of JS. You will be surprised. It was a rush hack job to.save a company from an existential threat. Like wasabi
    - wpietri 11y ago
      Sure, but that strikes me as the exception that proves the rule. JS succeeded not because of language merits, but because it had strong distribution. JS was basically held in contempt for a decade until the platforms and the language matured enough to make it useful for something more than button rollovers and form validation.

lenocinor 11y ago

"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." from How To Be A Programmer ( http://samizdat.mines.edu/howto/HowToBeAProgrammer.html#id2854864 http://samizdat.mines.edu/howto/HowToBeAProgrammer.html#id28... ).