I have seen many PHP improvement proposals over the years. I am really glad people are doing such things. But I would like to address something that seems a bit wrong-headed to me, that is common to many of these proposals.<p>PHP is a verbose language, it is known. It is not a bug, it is a feature. Yes, some languages like to make their source code look like it was gzip-compressed, and have one or two-character symbols for everything. PHP is not among those, and I don't see how writing "fn" instead of "function" really helps. Are you so lazy as to type "function"? Get a decent completing editor, it'll do it for you. But code saying "protected function sayHello()" is much better for everybody that one saying "pr fn sH()". Same goes for syntax like "!_->" - it looks like cartoon "expletive deleted" sequence, not like a readable code. PHP is not APL, it should be obvious to a reasonably knowledgeable person what goes on there.<p>The idea of space-as-syntax, the most known implementation of which is of course Python, has its advantages and disadvantages. I admire the cleanness of good python code, and and the same time I am greatly annoyed when I have my code break because there's some space instead of tab or tab instead of space or extra space somewhere where it is not obvious. But I'd be interested to see people try out "PHP with Python indentation syntax" and see how it works for them. I don't see it a big difference but would be an interesting idea to play with.
I don't know if I'm the only one, but I hate with passion this trend to remove syntax from a language and call it an improvement. It may be easier to code, but the code you produce is often more cryptic and harder to maintain. The aspect of the maintainability of a language is often disregarded even tough it's a very important aspect. That project is a very good example of this. Sacrificing readability for a few keystroke is never a good trade-off.
I think the reason this is getting negative/poor feedback is because the SAT analogy does not hold - Snow:PHP::CoffeeScript:JavaScript<p>JavaScript is a great language with debatable syntax. CoffeeScript works because it clarifies the beauty in the language. Snow doesn't do this for PHP because there isn't much beauty underlying the syntax to begin with.
While I don't rail against this kind of thing instinctively, I really do have to ask, is:<p><pre><code> pri fn render_row(row)
</code></pre>
<i>really</i> that much better than<p><pre><code> private function render_row($row) {
?</code></pre>
As something of a glorified preprocessor, there is a limit to how much it can "make the language better". However, they will probably be able to get a bit of hacker mileage out of code generation, and I can see how you could add features which would be handy (such as first-class anonymous functions; though good luck making that look like "idiomatic PHP code"). It is too bad, however, that they didn't decide to make HTML tags first-class entities in the language; although, of course, this is all vaporware at this point.<p>Anyone who is interested in new languages specifically designed for web programming should also check out: <a href="http://www.impredicative.com/ur/" rel="nofollow">http://www.impredicative.com/ur/</a>
Strip the comments from the PHP code and there isn't a drastic difference in size (as the snow example lacks comments), other than that, the PHP example is more readable. /shrugs
IMHO, you're trying too hard to fix the things which aren't broken in the first place. Covering the main flaws in PHP would be sufficient, e.g.<p><pre><code> str = 'foo'.replace('#', '').substr(1).as_array();
int = 5.something();
</code></pre>
would translate to<p><pre><code> $str = 'foo';
$str = str_replace('#', '', $str);
$str = substr($str, 1);
$str = (array) $str;
$int = 5;
$int = something($int);
</code></pre>
This would allow us to do things that aren't native to PHP but still have something much easier. Having strings, integers and other types used as objects (with a solid proxy syntax to the native functions) would be the first (and best) step forward.<p>Class definitions as well:<p><pre><code> Foo {
// constants
BAR = 'fubar',
BAR2 = 'foo';
// properties
protected _bar, _fubar;
// public properties / methods
public
bar() {
return ._bar;
},
fubar() {
return ._bar + ._fubar;
}
}</code></pre>
I've said it once and I'll say it again: if you're going to compile down to a language, support macros. CoffeeScript tries to make Javascript better, but I personally prefer Javascript's syntax. That's not to say CS doesn't have its benefits for many people, but one of the only things <i>missing</i> from Javascript is macros, so CS is pretty much worthless to me.<p>After spending countless hours in lisp and javascript, php leaves a <i>lot</i> to be desired. One of the things I do not desire is a language of equal power with a completely different syntax. Syntax is meaningless if it doesn't allow greater power.<p>Honestly, it's bad enough that CoffeeScript is so prevalent. I understand why it's around and why people like it, but I don't prefer it to pure JS...and I'd rather the trend not spread to other languages.<p>One possible candidate would be Pharen, though: <a href="http://scriptor.github.com/pharen/" rel="nofollow">http://scriptor.github.com/pharen/</a>.
What would be cooler is to use something like this as a basis to generate idiomatic php, python, perl or ruby. Let people sketch out their initial ideas in a common language, then compile in to a starter php project, or python project, etc.
Nice idea. Still a bit rough around the edges maybe? This certainly doesn't look as pure as snow:<p><pre><code> [!_->empty: "$row cannot be empty."]
</code></pre>
Good luck anyway!
Honestly I fail to see a more readable thing, having experience with PHP it is really hard to me to read the snow code. A lot of the syntax just doesnt make sense to me.<p>There is also another thing that annoys me, the significant whitespaces, that is something I do not like in python (while I like the rest of it, the indentation instead of brackets is annoying), yes I agree that indented code is more readable, and I like to read indented but I like to write my code without caring for indentation and fix it after it is doing what I want (read: tell my IDE to indent it, brackets help on that).
The replacement of .= for %= is just added confusion there is really no gain, and the return for <- seems just wrong looks like just a way to avoid using characters.
Dropping the semicolons doesnt make much difference to me, but being used to them it could be a problem, when writing in languages that dont require them I write them on habit leading to a long list of syntax errors.<p>Warning personal rant:
Why do people hate java like syntax and brackets WHYYYYYYYYYY? Whats wrong with brackets honestly???<p>Sorry just had to say that.
PHP as assembly language?<p>PHP does have a big advantage, it's unbiquity on low-cost web hosts that no other language can match. The downside is having to deal with PHP itself.<p>I'd like a platform of PHP-done-right but compiles to a set of .php files I can deploy to any webhost. I don't think this new language is it, but I'm happy to see developments.
This is syntactic sugar at best; other languages such as Python are cleaner <i>and</i> are more performant. Facebook's efforts to compile PHP to C++, HipHop, demonstrate this need, and in my opinion, this project is a step in the wrong direction.<p>PHP was great for its time, but sometimes you have to let grandpa go.
php as a target platform huhu, btw there was already php-reboot.<p>php reason to be is hosting + ecosystem, not linguistic qualities, too late for that.
Here's something constructive for all the haters. Snow is open source, seems with such a consensus it should be easy to get some people together and hack on a fork of snow that is more appealing to the masses. Or does the current PHP syntax leave nothing to be desired?
This might be a nice replacement for PHP spaghetti code you might see everywhere - see the recent HN thread where PHP is voted the most-hated language - it's because even solid coders produce spaghetti code with it. You need to be really disciplined to create something that's easily maintainable.<p>I would not touch PHP codebase without a framework. Some nice PHP frameworks have emerged in past few years ranging from simplest CodeIgniter to pretty complete Yii I use for most projects now. I would never choose to use PHP for a project without Yii or a similar framework, so until we see a quality framework written in PHPSnow, I don't see any reason to use it.
So much criticism... As usual the php community is resisting any change. I think what you are doing has a lot of merit. Your DSL just needs some polish.<p>What I like:<p>- The new return "<-"<p>What I think should change:<p>- The concatenating assignment operator "%=" shouldn't change. It should stay the same ".="<p>- Accessing instance variables/methods should be by using '@' rather than '.' as that is becoming an implied standard and php folk are already used to using '.' for string concatenation.<p>- The setting of parameter types and defaults on methods is too heavy and not what people expect. I would put them back into method declaration.<p><pre><code> eg.
@str title=null
class
# To become
class
fn constructor(str @title = null)
As @ would be the way to access instance variables what this means is the instance variable of title would be assigned the value that gets passed through the constructor.
# This is too much magic imo
@arr row
# List of integers.
[!_->empty: "$row cannot be empty."]
fn add_row(row)
# it should be something like this:
fn add_row(arr row)
!"$row cannot be empty." if row->empty
</code></pre>
- This doesn't make a lot of sense:<p><pre><code> for row in .rows
html %= "<table>" | .render_row(row) | "</table>"
# I would prefer something like:
html .= @render_row(row) for row in @rows
html = "<table>{html}</table>"
</code></pre>
Good work on what you have already achieved, with a bit of extra polish I think Snow can become very desirable.