PHP-Snow - A concise, dry and beautiful language that compiles to PHP
code.google.com
code.google.com
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.
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.
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.
A good editor will show you that too.
I like shortening fn though, as it often makes the difference if an expression containing an anonymous function can fit on one 80 character line or not.
About the "!_->" syntax in the validation part of the function definition. Recently I've decided to remove the entire validation part, because the syntax is too specific and weird. I still like the defining of arguments on top of the function because it removes duplicate argument names between docblocks and code. The idea of validation together with the argument defintion is still sound i think though.
<- 2
return 2
^ 2
2
This should not be an argument against language constructs which make languages more expressive, but there seems to be a trend where as languages move toward the functional end of the spectrum, they take on more and more terse and cryptic syntactical structures.
I've always felt that good code should read like a book. This can be reconciled with prefix notation, but not with overloading odd characters as operators.
People are creating new language in good faith and they want their language to look nice. I don't think anyone can disagree on that. The problem is that the aspect of the maintability of the code is overlooked in the process of the creation. When you overlook this aspect it may not hurt you in the short term, but it hurts in the long term. It may be nice for you to code something in a way now, but everyone that will have to maintain your code may not find it nice to read.
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.
But the real reasons I use Coffee script are the features it adds to the language: list comprehensions, splats, existential operator, severely concise class syntax.
And I don't see this offering any features that are as useful as those. The Snow code looks uglier, I think, than the PHP code. But if it looked uglier and gave me extra features (like, for instance, splats, comprihensions, improved slicing and range syntax, etc), I'd still probably use it.
I disagree. To each his own, I suppose. PHP inherited it's syntax structure from C, the language it's written in. Would you say that C is ugly?
pri fn render_row(row)
private function render_row($row) {
?And the @str title=null line above the class seems very odd.
I don't feel that it's more readable, or even easier to write, as "pri", though.
And the @str title=null line above the class seems very odd.
This is great because you can indent code under it that's relevant to it, that would normally end up cluttering your function's narrative up with housekeeping for variables.
This is a much more pleasant way to deal with PHP. Check out the documentation, it is outstanding. http://code.google.com/p/php-snow/wiki/Class
uhm, beautiful
What I'm not sure about is @arr (why not @array?) and [] instead of {} for a map...
I'm not sure if it's beautiful, but it's definitely an interesting shortcut for common operations and I could immediately see why it's useful and already remember the syntax for it. I like it and the author seems to like it too, not everyone has to agree of course ;)
[] instead of {} for a map
I don't think there's any difference between the two types in PHP. All lists are maps.
Anyone who is interested in new languages specifically designed for web programming should also check out: http://www.impredicative.com/ur/
PHP added anonymous functions in 5.3.
PHP: 66 Lines
- w/o PHPDoc: 45 Lines
-- w/ Single-line foreaches, exceptions, and ternary operators: 34 Lines
So if we use the same formatting, the PHP is only one line longer, and 5 of the lines are just end-braces.
Now, taking my condensed PHP, and the Snow code, and converting 4 spaces to a tab, the filesizes are:
Snow: 746b
PHP: 847b
Using a lazy comparison: 12% less code, roughly the same number of lines.
I'm with you - I don't see how using a completely different syntax & complicating your toolchain is worth it to save a handful of characters when typing. Maybe more example code (2k-3k lines) would help.
http://cl.ly/3Z3l1w0v2I2n2y231Y09/o
That's 10 lines more. 100 times more readable.
str = 'foo'.replace('#', '').substr(1).as_array();
int = 5.something();
$str = 'foo';
$str = str_replace('#', '', $str);
$str = substr($str, 1);
$str = (array) $str;
$int = 5;
$int = something($int);
Class definitions as well:
Foo {
// constants
BAR = 'fubar',
BAR2 = 'foo';
// properties
protected _bar, _fubar;
// public properties / methods
public
bar() {
return ._bar;
},
fubar() {
return ._bar + ._fubar;
}
}After spending countless hours in lisp and javascript, php leaves a lot 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.
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.
One possible candidate would be Pharen, though: http://scriptor.github.com/pharen/.
[!_->empty: "$row cannot be empty."]
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.
Warning personal rant: Why do people hate java like syntax and brackets WHYYYYYYYYYY? Whats wrong with brackets honestly???
Sorry just had to say that.
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.
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.
Is your webhost's DNS/email/DB service just not quite what you need? PHP devs can take their pick of a very wide selection of competing services.
PHP was great for its time, but sometimes you have to let grandpa go.
Your suggested approach would certainly add more drag for little gain for programming teams.
Developers would be better served optimizing performance, not messing around with simplifying syntax. For that reason, HipHop a worthwhile addition to the PHP canon; this not at all.
Optimizing performance and making writing/managing code easier are two different problems and not mutually exclusive. Code written in Snow can then be optimized with HipHop.
Python is just as "worthless" as Snow by the metric you're espousing here, because the benefits of Python over well-optimized C are in simplicity of reading and writing, not runtime performance.
php reason to be is hosting + ecosystem, not linguistic qualities, too late for that.
Bravo, for all the _wrong_ reasons.
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.
Everything that Gii does, you would have to write manually using PHPSnow. Doing that manually is slow and error prone.
Besides, using MVC framework makes the PHP code clean and maintainable, which are two real problems with PHP. Writing $this-> is a minor nuisance, but I hardly believe it warrants inventing a new language. If PHP is just ugly to you, why use it at all? There's Python, Ruby, whatever...
That's ridiculous -- PHP is pretty analogous to most languages in terms of both capability and syntax. The biggest warts in PHP revolve around the standard library and that wouldn't prevent anyone from producing solid code.
What I like:
- The new return "<-"
What I think should change:
- The concatenating assignment operator "%=" shouldn't change. It should stay the same ".="
- 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.
- 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.
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
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>"
This grinds my gears on a few levels - I really don't feel as though the reaction here is a resistance to change, as much as it is a resistance to completely redefining pretty much all of the core language constructs.
The Snow code is, in my eyes, almost completely unreadable, due to a seemingly random collection of characters.
I'm a PHP developer, and while I appreciate that (at times) PHP can be quite verbose, introducing such sweeping changes really doesn't make any sense to me. The add_row() function in particular is mind-bending for me. Auto-declaration (and initialisation, within a loop, no less) can only hurt in larger systems - which is why developing with notices enabled is such a plus.
I get annoyed with the php community because this thread embodies what a typical response from them is like. Criticize anyone trying to do something new by saying the old ways are best without giving any constructive feedback.
Also note. No one has to use Snow if they don't want to. These are not changes to the core of php, so it confuses me why people get so militant over the suggestion of a DSL for php.
As for your feedback itself - your own suggestions don't appear to improve readability in any meaningful way, mainly because the underlying example is simply so unreadable already.
I'm perfectly happy to debate potential layers above PHP to help with speedy development, but I'm also perfectly happy to argue against those that I don't believe have any promise.
You should expect criticism and taking is by falsely accusing the whole huge community of "resisting any change" is exactly the wrong way to do it.
I think the best part of the pre-processors is that it does not force the entire community to adopt the syntax and allows some to play with new language features.
> The concatenating assignment operator "%=" shouldn't change. It should stay the same ".="
The reason for using "%" was that I wanted to use "." for objects:
instance.my_method()
"{a_variable} and {a_method()}"
This looks weird, no:
@instance@var@subvar@sub_method()
> 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.
Yes it's heavy, but as you always need to have a docblock to write "acceptable" PHP code, I chose not to duplicate the argument names.
> This doesn't make a lot of sense.
No this should go, I decided that a couple of weeks too. But the problem its trying to solve is a real one. Your proposal looks good, but how would it work on a new variable?