5 ms·

I used haxe a lot in the past, but with the newer enhancements to JavaScript I found that I ended up using JavaScript. Destructuring assignment arrow function

by Lerc 8y ago

I used haxe a lot in the past, but with the newer enhancements to JavaScript I found that I ended up using JavaScript. Destructuring assignment arrow functions and more concise object literals, ... operator enable much more concise and readable code. Haxe seems to be much more conservative in development. Haze is aquiring arrow functions but I think there was quite a degree of initial resistance to the notion. I proposed a change to allow the new Javascript style consice object literals (simply allowing {fish,cheese} instead of {fish:fish,cheese:cheese} but was shut down with a 'we don't like it' I would prefer to use a independent language over one developed by a megacorp, but I fear Haxe will fall behind TypeScript due to their resistance to change. My own personal experience has motivate me to move to something else. The proposal I mentioned above left somewhat of a bad taste. The process went contrary to the processes listed. Notably The proposer is supposed to call a vote after discussion had concluded. Instead it was just shut down with a "we had a meeting and decided against it". I could give no counterargument because there was no argument to counter. I'm not against languages having a dictatorial model for development, but having a facade of an open process that carries no weight seems wrong.

dyarosla 8y ago
Sucks to hear about your experience. Like you said yes arrow functions are slated for the next major release. As for the process, I think it has become a little more stringent for sure. To submit a request for consideration you’d need to submit a proposal on GitHub with attention paid to impact to existing code and impact on future Haxe features- perhaps your feature request wasn’t deemed to be thought out enough? It also looks like you’d get more explicit consideration if you are a sponsor of the language (https://haxe.org/foundation/support-plans.html https://haxe.org/foundation/support-plans.html) So yes, while it isn’t a completely open vote, I also think most languages’ directions are decided by committee in a similar way. I’m sure the Haxe community would love to see examples of other communities with better practices to learn from.
- GordonS 8y ago
  > perhaps your feature request wasn’t deemed to be thought out enough? In which case surely it should be discussed, rather than shut down with "no"? This thread had me interested in Haxe, but reading these comments about the unfriendly, negative responses to proposals has put me right off.
  - dyarosla 8y ago
    To play devils advocate: if every feature request had to be thoroughly discussed you’d never get anywhere.. the onus should be on the proposer. That said, you can always file an issue in github and have a discussion there. For Haxe it’s a very active location for discussion there.
    - bendmorris 8y ago
      >the onus should be on the proposer I'll bite: what should @Lerc have done differently in his proposal (https://github.com/HaxeFoundation/haxe-evolution/pull/51 https://github.com/HaxeFoundation/haxe-evolution/pull/51)?
      - dyarosla 8y ago
        It seems like there’s some leeway in ‘After reaching general consensus or voting takes place, the PR is merged by someone from the Haxe developer team, and the proposal becomes "active". When merged, the proposal will receive its number from the corresponding pull request. If the proposal is rejected, the PR is closed with a comment explaining the reasons.’ I think general consensus was reached without a formal vote. Discussion was limited but explanation was given: language clarity would be impacted. A few main contributors agreed. @lerc didn’t provide much of a counterargument. That said, what would you have wanted to see done differently? A formal vote held? This proposal seemed to be a matter of preference, with no real consensus on clarity. Workarounds were even proposed. What would be your ideal resolution? Not shutting down the discussion as haphazardly? How much further should it have gone?
        8y ago
- deleted 8y ago
  [deleted]
- bendmorris 8y ago
  >perhaps your feature request wasn’t deemed to be thought out enough? Why the automatic defense of the Haxe team? Frankly, small communities like this sometimes come across as cult-like in their response to criticism, and it isn't a good look. Here's the proposal in question: https://github.com/HaxeFoundation/haxe-evolution/pull/51 https://github.com/HaxeFoundation/haxe-evolution/pull/51 Here's the process which wasn't followed: https://github.com/HaxeFoundation/haxe-evolution https://github.com/HaxeFoundation/haxe-evolution. Very little discussion, no public vote, even though the proposer put in the effort and clearly wanted to engage. When someone puts in the effort to make a proposal like this, this bait and switch is not a way to keep them around, and insulting them in HN comments isn't any better.
  - dyarosla 8y ago
    Where’s the insult? I can’t speak for the community or who did what. If anything I’m looking to see what can be done going forward.
    - bendmorris 8y ago
      To quote you again: >perhaps your feature request wasn’t deemed to be thought out enough? Why jump to finding fault with the OP, rather than accepting feedback about the process? AFAICT you didn't actually check OP's proposal before assuming it was lacking. And OP's experience isn't unique. You're evangelizing Haxe in this thread, but here you just paper over valid criticism: - "arrow functions are slated for the next major release": sure, it only took four years! - "I also think most languages’ directions are decided by committee in a similar way": I'm not aware of any other language that has a proposal process inviting community participation, but doesn't follow it and discusses those proposals in private. Point me to one. Surely you can understand that this can be frustrating when someone tries to participate and is shut out. - "I’m sure the Haxe community would love to see examples..." I would be pleasantly surprised if I saw the Haxe Foundation engage in some introspection and actually take steps to change or at least be more transparent. So far I don't see any introspection, only defensiveness. And FWIW, I used to be part of that internal Slack channel for team members and was a Haxe contributor. I tried to make progress on these issues for years before giving up.
bendmorris 8y ago
Similar experience here. I've proposed a few changes to the language and none have been accepted. Rejecting convenience features with no downside like concise object literals is unfortunate. It literally took over four years to finally get arrow functions into Haxe, which had overwhelming community support. Change proposals are subjective, so people can have different opinions on whether a change should be accepted or whether it was well-formulated enough. What bugs me though is that the Haxe team has a documented process for considering and voting on these proposals, which they don't follow. If Nicolas doesn't like a feature, it's essentially vetoed. If he changes his mind later, it'll be implemented without any further discussion. Most discussion happens in an internal Slack channel so there's no transparency. It's essentially a BDFL masquerading as a democracy, and it can be frustrating to try to contribute as an outsider if you don't realize that. See inline XML for example (https://github.com/HaxeFoundation/haxe-evolution/pull/26 https://github.com/HaxeFoundation/haxe-evolution/pull/26) - a lot of discussion, open questions remaining, seemed like Nicolas was generally resistant. Then suddenly, there's a PR and it's merged, and it will be in the next version of Haxe. IMO, this is not the way to run an open source project. And in my experience, the team is resistant to feedback and takes things personally, so I've lost confidence that it will change.
- ncannasse 8y ago
  Hi ben, it's clearly not the best place to discuss this, but I still wanted to leave you some message here, hope it'll reach you. I don't think that you get a good language by having design by committee. I'm all for democratic process and contributions in many different areas, but you simply can't apply that to language design, but you really need a way to understand and see the big picture, and not only reason about a particular local feature. The only thing we could do better here would be to spend more time motivating my decisions so they seem less random to people from outside, but it's time consuming to do so and I'm sadly lacking the time for it. I understand how this can be badly perceived but you shouldn't put ill intend behind what has happened to your proposals. Also, I saw you started designing your own language, which is very different from Haxe from what I have seen, so it seems to me what you wanted Haxe to be was simply not what it is and will be.
  - 8y ago

by Lerc 8y ago

dyarosla 8y ago

Sucks to hear about your experience. Like you said yes arrow functions are slated for the next major release. As for the process, I think it has become a little more stringent for sure. To submit a request for consideration you’d need to submit a proposal on GitHub with attention paid to impact to existing code and impact on future Haxe features- perhaps your feature request wasn’t deemed to be thought out enough? It also looks like you’d get more explicit consideration if you are a sponsor of the language (https://haxe.org/foundation/support-plans.html https://haxe.org/foundation/support-plans.html) So yes, while it isn’t a completely open vote, I also think most languages’ directions are decided by committee in a similar way. I’m sure the Haxe community would love to see examples of other communities with better practices to learn from.

GordonS 8y ago
> perhaps your feature request wasn’t deemed to be thought out enough? In which case surely it should be discussed, rather than shut down with "no"? This thread had me interested in Haxe, but reading these comments about the unfriendly, negative responses to proposals has put me right off.
- dyarosla 8y ago
  To play devils advocate: if every feature request had to be thoroughly discussed you’d never get anywhere.. the onus should be on the proposer. That said, you can always file an issue in github and have a discussion there. For Haxe it’s a very active location for discussion there.
  - bendmorris 8y ago
    >the onus should be on the proposer I'll bite: what should @Lerc have done differently in his proposal (https://github.com/HaxeFoundation/haxe-evolution/pull/51 https://github.com/HaxeFoundation/haxe-evolution/pull/51)?
    - dyarosla 8y ago
      It seems like there’s some leeway in ‘After reaching general consensus or voting takes place, the PR is merged by someone from the Haxe developer team, and the proposal becomes "active". When merged, the proposal will receive its number from the corresponding pull request. If the proposal is rejected, the PR is closed with a comment explaining the reasons.’ I think general consensus was reached without a formal vote. Discussion was limited but explanation was given: language clarity would be impacted. A few main contributors agreed. @lerc didn’t provide much of a counterargument. That said, what would you have wanted to see done differently? A formal vote held? This proposal seemed to be a matter of preference, with no real consensus on clarity. Workarounds were even proposed. What would be your ideal resolution? Not shutting down the discussion as haphazardly? How much further should it have gone?
      - 8y ago
deleted 8y ago
[deleted]
bendmorris 8y ago
>perhaps your feature request wasn’t deemed to be thought out enough? Why the automatic defense of the Haxe team? Frankly, small communities like this sometimes come across as cult-like in their response to criticism, and it isn't a good look. Here's the proposal in question: https://github.com/HaxeFoundation/haxe-evolution/pull/51 https://github.com/HaxeFoundation/haxe-evolution/pull/51 Here's the process which wasn't followed: https://github.com/HaxeFoundation/haxe-evolution https://github.com/HaxeFoundation/haxe-evolution. Very little discussion, no public vote, even though the proposer put in the effort and clearly wanted to engage. When someone puts in the effort to make a proposal like this, this bait and switch is not a way to keep them around, and insulting them in HN comments isn't any better.
- dyarosla 8y ago
  Where’s the insult? I can’t speak for the community or who did what. If anything I’m looking to see what can be done going forward.
  - bendmorris 8y ago
    To quote you again: >perhaps your feature request wasn’t deemed to be thought out enough? Why jump to finding fault with the OP, rather than accepting feedback about the process? AFAICT you didn't actually check OP's proposal before assuming it was lacking. And OP's experience isn't unique. You're evangelizing Haxe in this thread, but here you just paper over valid criticism: - "arrow functions are slated for the next major release": sure, it only took four years! - "I also think most languages’ directions are decided by committee in a similar way": I'm not aware of any other language that has a proposal process inviting community participation, but doesn't follow it and discusses those proposals in private. Point me to one. Surely you can understand that this can be frustrating when someone tries to participate and is shut out. - "I’m sure the Haxe community would love to see examples..." I would be pleasantly surprised if I saw the Haxe Foundation engage in some introspection and actually take steps to change or at least be more transparent. So far I don't see any introspection, only defensiveness. And FWIW, I used to be part of that internal Slack channel for team members and was a Haxe contributor. I tried to make progress on these issues for years before giving up.

bendmorris 8y ago

Similar experience here. I've proposed a few changes to the language and none have been accepted. Rejecting convenience features with no downside like concise object literals is unfortunate. It literally took over four years to finally get arrow functions into Haxe, which had overwhelming community support. Change proposals are subjective, so people can have different opinions on whether a change should be accepted or whether it was well-formulated enough. What bugs me though is that the Haxe team has a documented process for considering and voting on these proposals, which they don't follow. If Nicolas doesn't like a feature, it's essentially vetoed. If he changes his mind later, it'll be implemented without any further discussion. Most discussion happens in an internal Slack channel so there's no transparency. It's essentially a BDFL masquerading as a democracy, and it can be frustrating to try to contribute as an outsider if you don't realize that. See inline XML for example (https://github.com/HaxeFoundation/haxe-evolution/pull/26 https://github.com/HaxeFoundation/haxe-evolution/pull/26) - a lot of discussion, open questions remaining, seemed like Nicolas was generally resistant. Then suddenly, there's a PR and it's merged, and it will be in the next version of Haxe. IMO, this is not the way to run an open source project. And in my experience, the team is resistant to feedback and takes things personally, so I've lost confidence that it will change.

ncannasse 8y ago
Hi ben, it's clearly not the best place to discuss this, but I still wanted to leave you some message here, hope it'll reach you. I don't think that you get a good language by having design by committee. I'm all for democratic process and contributions in many different areas, but you simply can't apply that to language design, but you really need a way to understand and see the big picture, and not only reason about a particular local feature. The only thing we could do better here would be to spend more time motivating my decisions so they seem less random to people from outside, but it's time consuming to do so and I'm sadly lacking the time for it. I understand how this can be badly perceived but you shouldn't put ill intend behind what has happened to your proposals. Also, I saw you started designing your own language, which is very different from Haxe from what I have seen, so it seems to me what you wanted Haxe to be was simply not what it is and will be.
- 8y ago