They didn't make it very clear, but I think the embedded SQL idea is meant to be for things like querying against collections, similar to LINQ[1]. Even it's meant for databases, it's still up to you where in the app you put it.

That being said, my initial reaction is to wonder why, when designing a new language, one would model after PHP of all things.

1: http://en.wikipedia.org/wiki/Language_Integrated_Query

Yeah I'm also not a fan of linq. Or at least not in my PHP.

I think something like underscore.js[1] would be much more in the style of PHP - I always thought PHP and JS were similary in their wackiness - and I would much prefer it to LINQ.

As far as modeling after PHP, there are things I'd leave/take, but really the biggest issue is the standard library.

1: http://brianhaveri.github.com/Underscore.php/

+1. wish I'd seen underscore.php sooner!

Really? It's cleaner to have queries represented as strings than as a language-integrated syntax that can throw errors at compile time? To each their own, but if I had to guess, I'd say you've got a minority opinion there.

I doubt it's a minority opinion, at the very least amongst PHP devs. Having it as a string allows me to pass it to a logging function, or output it in a debug console, or send it to a query pre-processor that adds the right database prefix for the current app, etc.

You never lose capabilities by adding semantic structure. It's trivial to flatten that out with a toString of some kind.

As encoderer said, you can definitely do that in Linq. The query operators basically just map to methods, which are overridden by the different providers... The SQL ones basically create SQL statements for you behind the scenes (as log gable strings).

I thought it was all kind of weird and wrong at first too but now it's probably my favorite c# feature next to the (very much related) lambda expressions, especially for non-SQL collection queries. Of course this doesn't mean PHP needs integrated queries or anything, but it is a very nice feature to have if done right. XML/json literals, on the other hand, do feel kind of wrong to me though (although I bet they are handy still, as many vb.net devs will probably attest to).

[Edited for spelling - damn ipad keyboard!]

You're making the assumption that you'd lose that functionality if you moved to a language integrated query? Not so.

Take a look at the Linq implementation for a good example. Or, look at something like JSON in javascript.

"- I'm also personally a fan of the dollar sign."

May i ask why? i think that this makes the languaje very ugly.

Here's a contrived example to demonstrate the value of sigils:

    /* in version x of SFL (Sigil-Free Language) */

    school = get_school("Saint Fred's School For Girls");
    class = get_class(school, "Agricultural Studies", 12);
    yield = get_agricultural_yield(class, "Turnips", 2011);
    printf("The Year 12 Ag Studies class produced %d turnips in 2011", yield);

Now we try upgrading to version x+1 of SFL, which adds object-orientation and concurrency (it was a BIG upgrade!). Now three of the lines in that four-line program contain errors, because "class" and "yield" are no longer valid variable names, having been turned into keywords.

In a language with sigils, that's no problem. It also makes it easier (therefore faster) for syntax highlighting to spot where variables are used, without needing a full dictionary and an exact version number - that makes a difference for me as an Emacs user especially.

While true, it's a very minor deal because the scenario you've described:

- Happens very rarely - Is trivially solved, even in a large codebase

You could just look at that as an argument against keywords, rather than for sigils, ala Smalltalk and Lisp.

I like it as well, it makes it very clear what is a variable and what is some other sort of identifier.

etfb is on the right path, but for me it just feels right. I guess that's just a personal preference, but the dollar sign is a visual indicator that a particular string is a variable, and not a function call.

For me, it makes a big difference in languages like ruby where you could either be calling a method, a monkey-patched method_missing callable, or a property in some scope.

Well, in PHP you already have a mandatory '()' at the end of function call - so it's pretty hard to confuse the two.

Additionally if your language has first class functions, it would feel kind of strange if names of some functions started with $ and others without it.

Good point. If variables can be functions and functions can be represented by variables, variable naming rules would to apply to functions both declared and assigned. Which is to say all functions. The $sigil would have to melt away or be everywhere.