Hacker News Reader

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

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.

Actually, car analogies are the Rolls-Royces of analogies.

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.

"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#id28... ).

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

Didn't Python, Ruby, JavaScript, CoffeeScript, Perl and PHP all start as essentially side projects or hobbies?

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.

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

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.

I've been holding it in contempt for two decades and doubt I will ever stop. Spending some time on a static analysis project for JS recently only reinforced that opinion.

Fair point. Perhaps we can say people have shifted from utter contempt to grudging tolerance?

I can agree with that!

rails? php?

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

yeah, and the answer is "No"

Not really a better answer. It'd be better to take a well-designed, "top" language, and output JS or WAS from that.