

PHP-Snow - A concise, dry and beautiful language that compiles to PHP - dyscrete
http://code.google.com/p/php-snow/

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

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.

~~~
runekaagaard
WOW, I'm on hackernews, wow! I completely agree on not shortening array,
object, private, public, etc. I reached a similar decision a while ago, but
didn't get around to fixing the docs.

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.

~~~
wvenable
Perhaps function should be allowed in both long and short form. I might be
willing to use fn for an anonymous function but much less likely in regular
situations.

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

~~~
andybak
Isn't the aim here to improve readability?

~~~
pietro
By which measure is

    
    
        <- 2
    

easier to read than

    
    
        return 2
    

There are many more examples in the code, but I generally found the PHP code
MUCH easier to read, and I don't know PHP very well. It could be that I'm
biased towards C-like languages, but I doubt it; words are a lot easier to
read than arbitrary symbols.

~~~
protomyth
I wouldn't have blinked if it was:

    
    
      ^ 2
    

since that is what is used in Smalltalk, but the left arrow makes me think I
am missing what it should point to.

~~~
JonnieCache
In ruby you could just write

    
    
      2
    

assuming you're at the end of a function. Coffeescript is the same iirc.

------
lunaru
I think the reason this is getting negative/poor feedback is because the SAT
analogy does not hold - Snow:PHP::CoffeeScript:JavaScript

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.

~~~
encoderer
That could be true.

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.

------
danielhunt
While I don't rail against this kind of thing instinctively, I really do have
to ask, is:

    
    
      pri fn render_row(row)
    

_really_ that much better than

    
    
      private function render_row($row) {
    
    ?

~~~
badboy
Speaking of readability: Just `pri` as the constructor? When having just a
quick glance at code I want to know which part does what. Function names help,
even if it is ___construct_.

And the _@str title=null_ line above the class seems very odd.

~~~
danielhunt
I'm not sure I understand your comment - the function name in this case is
"render_row()", and "pri" refers to the visibility of the function.

I don't feel that it's more readable, or even easier to write, as "pri",
though.

~~~
badboy
_pri_ is used first for the constructor (right after _class SumTable_ ) but
not followed by any name. I find it quite hard to read this way.

~~~
danielhunt
Ah - I missed that entirely, thanks for pointing it out again. That line may
just win the prize for least-clear line in the Snow example.

------
zalew
@arr pri fn [!_->empty:

uhm, beautiful

~~~
viraptor
Depends on the languages you're familiar with... fn is common in some areas, _
is a popular "default variable", -> I see as an interesting addition although
it would be equivalent to empty(_).

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 ;)

~~~
andypants

      [] instead of {} for a map
    

PHP uses [] for both list and map types.

I don't think there's any difference between the two types in PHP. All lists
are maps.

~~~
daeken
But we're talking syntax, not behavior. There's no reason they couldn't use {}
to indicate maps and [] to indicate lists, even if they're the same data type.
The point of this language is to be a cleaner syntax on top of PHP, so
syntactical sugar like that is a Good Thing (TM).

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

Anyone who is interested in new languages specifically designed for web
programming should also check out: <http://www.impredicative.com/ur/>

~~~
mcantelon
>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")

PHP added anonymous functions in 5.3.

<http://php.net/manual/en/functions.anonymous.php>

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

~~~
whichdan
Snow: 33 Lines

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.

~~~
guillermovs
Here's a side by side comparison without comments:

<http://cl.ly/3Z3l1w0v2I2n2y231Y09/o>

That's 10 lines more. 100 times more readable.

~~~
runekaagaard
Well actually 15, as it seems fair to remove the comments in Snow too. About
it being readable, I think that has a lot to do with experience. For me the
Snow version is clear as day ;)

~~~
guillermovs
Well the comments in Snow are kinda necessary, since it's all abbreviated and
hard to read. The PHP class in the other hand is a lot clearer, with
informative class and function names.

------
orblivion
Can we start talking about this trend of people referring to their own work as
beautiful? It seems kindof tasteless to me, am I alone here?

~~~
jarek
But if you don't call your work Beautiful how will people know you have Taste?
When you're Intelligent and Creative you just have to show it.

------
antihero
I personally don't like the shortening of words. Having a long word doesn't
really hurt readability.

------
afsina
I think Php is concise enough. Sory for being harsh but this looks like evil
twin of Perl.

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

    
    
        str = 'foo'.replace('#', '').substr(1).as_array();
        int = 5.something();
    

would translate to

    
    
        $str = 'foo';
        $str = str_replace('#', '', $str);
        $str = substr($str, 1);
        $str = (array) $str;
        
        $int = 5;
        $int = something($int);
    

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.

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;
            }
        }

------
orthecreedence
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 _missing_ from Javascript
is macros, so CS is pretty much worthless to me.

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

------
krsunny
How long before people start writing compilers that pre-compile the pre-
compiliers?

~~~
chc
That would be pointless in most cases, whereas the history of computing has
pretty well established that preprocessors are useful.

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

------
h2s
Nice idea. Still a bit rough around the edges maybe? This certainly doesn't
look as pure as snow:

    
    
        [!_->empty: "$row cannot be empty."]
    

Good luck anyway!

~~~
runekaagaard
Nope that is way too magic. It will go away. :)

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

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.

------
billpg
PHP as assembly language?

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.

~~~
pork
This is outdated, I can find you a handful of hosts that offer Perl, Python
and Ruby for under five bucks a month.

~~~
billpg
Sure, they exist, but these other languages have nowhere near the ubiquity of
PHP in the economy webhosting world. PHP devs have plenty of choices.

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.

~~~
pork
Please back up what you're saying with some proof. As I said, PHP is no longer
the most ubiquitous economy hosting language.

------
ericfrenkiel
This is syntactic sugar at best; other languages such as Python are cleaner
_and_ 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.

PHP was great for its time, but sometimes you have to let grandpa go.

~~~
mcantelon
Sometimes you're stuck with large PHP codebases.

~~~
ericfrenkiel
very true, though how would this project help? A major rewrite would have to
be done with PHP-Snow just as much as another language.

~~~
mcantelon
If you were adding to the codebase, you could write the code using Snow. You
could also rewrite select portions that you regularly need to work on, as
opposed to having to port the entire codebase to another language.

~~~
ericfrenkiel
Again, what is the advantage to be gained by simply reducing syntax?
Programming efficiency? Saving a few key strokes?

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.

~~~
mcantelon
Reducing syntax noise can theoretically make code easier to read and write. I
personally don't go for that approach, but others swear by it and if it
increases their productivity and makes them happier then that's a good thing.

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.

------
rman666
Yay, another language!

~~~
hellerbarde
indeed :) Competition breeds innovation, competition breeds excellence!

------
agumonkey
php as a target platform huhu, btw there was already php-reboot.

php reason to be is hosting + ecosystem, not linguistic qualities, too late
for that.

------
kleiba
I guess beauty lies in the eye of the beholder.

------
joshfraser
i value conciseness, but clarity matters more. i guess that's why the longer i
code, the longer my variable names become.

------
user2459
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?

------
jonniekang
not as pretty as ruby or coffee-script :P

------
yakko
yay let's copy ruby and python!

------
eXpl0it3r
How can anyone call this beautiful? o.O

------
umen
why? do php to native c do very simple language to native c

------
caiusdurling
As I said on twitter, someone finally managed to write a more pointless and
retarded abstraction than HAML.

Bravo, for all the _wrong_ reasons.

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

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.

~~~
sciurus
Why couldn't you use an existing PHP framework from PHPSnow?

~~~
babuskov
Take Yii for example. Beside framework functionality, the power of rapid
development comes from Gii code-generation tool and it generates PHP code
(complete MVC for CRUD + admin. interface based on database tables or PHP
class). You get skeleton structure that you need to fill in with your business
logic (and put some design into views, but that's not really a problem here).

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

~~~
codesuela
then again PHP is arguably a framework itself and when dealing with something
either very simple or very complex Yii feels to verbose.

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

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
    
        

\- This doesn't make a lot of sense:

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

Good work on what you have already achieved, with a bit of extra polish I
think Snow can become very desirable.

~~~
danielhunt
> So much criticism... As usual the php community is resisting any change.

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.

~~~
coenhyde
I didn't say Snow was perfect. Far from it. Didn't you see my long list of
feedback?

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.

~~~
danielhunt
I did indeed see your feedback, but it was the opening comment that framed the
feedback, that bothered me most.

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.

