Hacker News Reader

Comment by dyarosla | Hacker News Reader

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)

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.

View on HN

>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

Here's the process which wasn't followed: 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.

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.

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.

I’m sorry if I’ve come off defensive or as finding fault. I’m not trying to defend the action, merely trying to gauge the entire situation. There’s reason for why I used the word perhaps and asked for more info. If the process is as bad as it is from what you and others are saying, I’d love to hear more about the efforts made to fix the process and details on where/ why you think they didn’t pan out? Is it a problem with the leadership? Something else?

I do evangelize the language and have not myself run into these issues as of yet. If they do exist my hope is also to have them resolved, not to justify them away and keep the status quo.

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

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.

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

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?

I didn't give much of a counterargument because there was hardly any argument to counter. If the issue had not have been closed so quickly I would have pressed people for specifics of what they thought were wrong. At the time I believed I was the person responsible for calling the vote so I was prepared to give them time to provide a coherent argument.

I think at the end of the day there was simply no interest in the proposal. Nadako was "not opposed to it" but that was about it. Personally, I would have liked to not have seen the conversation ended with a "that's what we decided elsewhere" message.

That being said, this particular proposal seems like a matter of opinion (on the level of tabs vs spaces) to which no amount of argument would have really swayed people. Definitely something to learn from here. Thank you for sharing your story!

I feel like you are missing the point here. Project maintainers can behave like absolute arbitors if they want to. Many projects successfully work by this mechanism. The issue as stake here isn't how they decided on the proposal but rather that the way that they decided on the proposal is different to the processes that they specified.

They are soliciting contributions by promising an open process ( see https://github.com/HaxeFoundation/haxe-evolution#voting-proc... ) but disregarding those processes when they feel like it.

Ironically, the discussion we are having here is much closer to the level of engagement that should have happened there.

As a sidenote, I'm just curious, what do you personally think of the proposal? Would you like to have the concise object literal notation in Haxe?

I think I posted in a parent comment that I think they did follow the (somewhat arbitrarily defined process) if you give leeway to the phrase "After reaching general consensus or voting takes place"; whereas it seemed like a general consensus was reached in that situation. I think a clearer process that's a little more transparent would definitely be beneficial, including clearing up that phrasing.

On the sidenote, I personally don't run into many (if any) situations where I would use concise object literal notation. I'm on the fence as to the issue of clarity and whether it would help/detract/be neutral for Haxe.

The style of concise object literals is fairly inconsistent with the rest of the language at the current time, and I could see how it could lead to clarity/confusion issues. Because I believe it's more of a syntactic sugar than anything else I am leaning to agree that macros may be the way to go for it.

I just checked the link to the proposal and I don't think there was anything wrong.

A little discussion about the proposal. Some didn't seem to like it because of 'language clarity'. Some group of core developers discussed it and rejected it.

I don't know what one expects but I have seen quite some language proposals (rejected) and this didn't seem inappropriate to me. They don't want it.. accept it or move on. They gave a reason. If you think it's sufficient is another thing and mostly about opinion.

Reply on news.ycombinator.com