3 ms·

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

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 15y ago
> 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 15y ago
  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 15y ago
    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.
  - wvenable 15y ago
    So any criticism of this is the "PHP community resisting change" -- that's rather convenient. I suspect many of the people criticizing both this language and the approach here aren't even PHP programmers.
smsm42 15y ago
"As usual the php community is resisting any change." This is obviously false statement. There were a lot of changes in PHP lately. However, PHP community is a huge community, millions strong, and it is natural that some people evaluate new things not only on coolness, but on practical and other criteria, and not everybody likes the changes - it would be very hard to produce a big change that is universally liked by millions (unless it has letter "i" in front, of course - so if you called it iSnow you'd have much better chance ;). 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.
mattmiller 15y ago
The only constructive comment in the thread has been sunk by downvotes. I don't know why people hate these pre-processors so much. Coffeescript threads always have a fair amount of people complaining although Coffeescript has been pretty successful. 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.
- wvenable 15y ago
  Pre-processors start at -100 points -- the complexity of adding to the tool chain, the leaky abstractions, the extra difficulty in debugging, the fact you have to know two languages well to be effective, and so on. A pre-processor has to be really good and really clever to be worth the overhead.
  - mattmiller 15y ago
    The point is: if you don't like it you don't have to use it. PHP still stands in its current form. Snow may become popular with a minority of more adventurous devs and develop into something that you may want to use.
    - wvenable 15y ago
      The fact that you don't have to use it means that it's beyond criticism? What point are you trying to make? You don't have to use PHP either.
runekaagaard 15y ago
Thank you so, so, so much for actual constructive criticism!!! > 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() I don't think "%" will be used as much due in Snow, due to the new "smart strings": "{a_variable} and {a_method()}" > 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. This looks weird, no: @instance@var@subvar@sub_method() and what about accessing static vars and methods? > 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?

danielhunt 15y ago

> 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 15y ago
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 15y ago
  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.
- wvenable 15y ago
  So any criticism of this is the "PHP community resisting change" -- that's rather convenient. I suspect many of the people criticizing both this language and the approach here aren't even PHP programmers.

smsm42 15y ago

"As usual the php community is resisting any change." This is obviously false statement. There were a lot of changes in PHP lately. However, PHP community is a huge community, millions strong, and it is natural that some people evaluate new things not only on coolness, but on practical and other criteria, and not everybody likes the changes - it would be very hard to produce a big change that is universally liked by millions (unless it has letter "i" in front, of course - so if you called it iSnow you'd have much better chance ;). 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.

mattmiller 15y ago

The only constructive comment in the thread has been sunk by downvotes. I don't know why people hate these pre-processors so much. Coffeescript threads always have a fair amount of people complaining although Coffeescript has been pretty successful. 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.

wvenable 15y ago
Pre-processors start at -100 points -- the complexity of adding to the tool chain, the leaky abstractions, the extra difficulty in debugging, the fact you have to know two languages well to be effective, and so on. A pre-processor has to be really good and really clever to be worth the overhead.
- mattmiller 15y ago
  The point is: if you don't like it you don't have to use it. PHP still stands in its current form. Snow may become popular with a minority of more adventurous devs and develop into something that you may want to use.
  - wvenable 15y ago
    The fact that you don't have to use it means that it's beyond criticism? What point are you trying to make? You don't have to use PHP either.

runekaagaard 15y ago

Thank you so, so, so much for actual constructive criticism!!! > 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() I don't think "%" will be used as much due in Snow, due to the new "smart strings": "{a_variable} and {a_method()}" > 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. This looks weird, no: @instance@var@subvar@sub_method() and what about accessing static vars and methods? > 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?