>> 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.
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)
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.
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.
It seems to make sense to write a language that maps at a high level to a specific business domain. Query is firmly within the technical domain, not a business domain. It's not surprising that a custom query language would have trouble scaling relative to a commercial query stack from a team of people who live and breath queries for a living and make that living in a commodified market.
On the other hand, there really wasn't anything approaching an off the shelf solution to FogCreek's business problem, and even with massively popular legacy languages there rarely is (it takes an IBM to first productize a COBOL to Java compiler). FogCreek's strategy worked well enough that customer's were writing checks that didn't bounce, and that's pretty good for a software product.
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.